Date: Mon, 13 Sep 1999 20:19:44 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) Message-ID: <Pine.OSF.4.05.9909132010200.7389-100000@oracle.dsuper.net> In-Reply-To: <199909131840.OAA31048@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 13 Sep 1999, Garrett Wollman wrote: !><<On Sun, 12 Sep 1999 23:19:13 -0400 (EDT), Bosko Milekic <bmilekic@dsuper.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.4.05.9909132010200.7389-100000>