From owner-freebsd-security Tue Sep 14 0:52:50 1999 Delivered-To: freebsd-security@freebsd.org Received: from sonet.crimea.ua (OTC-sl3-FLY.CRIS.NET [212.110.136.71]) by hub.freebsd.org (Postfix) with ESMTP id 980F614F91; Tue, 14 Sep 1999 00:52:02 -0700 (PDT) (envelope-from stas@sonet.crimea.ua) Received: (from stas@localhost) by sonet.crimea.ua (8.8.8/8.8.8) id KAA08988; Tue, 14 Sep 1999 10:50:43 +0400 (MSD) (envelope-from stas) Date: Tue, 14 Sep 1999 10:50:43 +0400 (MSD) From: Stas Kisel Message-Id: <199909140650.KAA08988@sonet.crimea.ua> To: bmilekic@dsuper.net, wollman@khavrinen.lcs.mit.edu Subject: Re: mbuf shortage situations (followup) Cc: avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG, stas@sonet.crimea.ua In-Reply-To: <199909131840.OAA31048@khavrinen.lcs.mit.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > From wollman@khavrinen.lcs.mit.edu Mon Sep 13 22:39:37 1999 > > I'm also aware of the possiblity of some people not liking the > > fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). > > I don't have any problem with sleeping forever -- but I am concerned > about the possibility of deadlock, especially when client-NFS is > involved. If the problem just moves around and has harder-to-recover > symptoms, the change isn't helping. IMHO merely sleeping can't help if we deal with a DoS. Instead of sleeping, kernel should find out where all kernel memory is wasted and free some memory (and, probably, remove/log reason). And, partially, this mechanism is already implemented in ip_drain() and tp_drain(). -- Stas Kisel. UNIX, security, C, TCP/IP, Web. UNIX - the best adventure game http://www.tekmetrics.com/transcript.shtml?pid=20053 http://www.crimea.edu +380(652)510222,230238 ; stas@crimea.edu stas@sonet.crimea.ua ; 2:460/54.4 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message