From owner-freebsd-security Mon Sep 13 17:19:56 1999 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 566A515251; Mon, 13 Sep 1999 17:19:46 -0700 (PDT) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id UAA12720; Mon, 13 Sep 1999 20:19:44 -0400 (EDT) Date: Mon, 13 Sep 1999 20:19:44 -0400 (EDT) From: Bosko Milekic To: Garrett Wollman Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) In-Reply-To: <199909131840.OAA31048@khavrinen.lcs.mit.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 13 Sep 1999, Garrett Wollman wrote: !>< said: !> !>> This message is in MIME format. The first part should be readable text, !>> while the remaining parts are likely unreadable without MIME-aware tools. !>> Send mail to mime@docserver.cac.washington.edu for more info. !> !>It would be preferable if text were sent as text, since MIME-encoded !>patches require more effort to read. !> I deffinately agree. This is obviously my mistake, and I was somewhat in a rush, very lagged (modem, eurgh), using pine, and made several [dumb] typos in the 'Attatchement' field. !>> 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. Well, the main purpose of the code is to basically sleep until something is freed after we've already exhausted the mb_map arena (as I'm sure you've seen if you were able to grab the attachements). This is really a-la-limite stuff. In other words, if 'normal' local programs are having trouble because of mb_map exhaustion, then maxusers && nmbclusters would have to be augmented. !> !>The 4.3BSD code had two different behaviors: !> !> - For clusters, if M_WAIT was specified and there was no space !>left in mb_map, it panicked. However, m_clalloc was never called with !>M_WAIT, so that panic was effectively dead code. Hmmm. If m_clalloc was never called with M_WAIT, then all the code calling m_clalloc deffinately checked its return value. It probably had specific ways to deal with m_clalloc returning failures, too? !> !> - For mbufs, if M_WAIT was specified and there were no mbufs !>available, it would sleep at PZERO - 1 (which was interruptible). !> !>In 4.3, the code was able to deal with cluster allocation failing. We !>have a somewhat different situation now, because many network !>interface devices have less-flexible DMA mechanisms which don't allow !>packet reception into non-contiguous buffers, so we need to have at !>least a certain number of clusters available for this purpose. Exactly. This is the next challenge. As for things being interruptable, as I mentionned to a reply to Matt Dillon just a few seconds ago, getting the tsleep to occasionally expire is trivial. As you say above, it's dealing with the failure that is the issue. !> !>-GAWollman !> !>-- !>Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same !>wollman@lcs.mit.edu | O Siem / The fires of freedom !>Opinions not those of| Dance in the burning flame !>MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick !> Cheers, Bosko Milekic. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message