Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 5 Sep 1999 21:18:47 -0700 (PDT)
From:      Matthew Dillon <dillon@apollo.backplane.com>
To:        Bosko Milekic <bmilekic@dsuper.net>
Cc:        freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG
Subject:   Re: mbuf shortage situations
Message-ID:  <199909060418.VAA70623@apollo.backplane.com>
References:   <Pine.OSF.4.05.9909052312260.25081-100000@oracle.dsuper.net>

next in thread | previous in thread | raw e-mail | index | archive | help
:	The only reason that I see for which we would actually panic() in
:this situation (as opposed to suffer the packet loss) is if we get to the
:point where we're losing packets because some script kid starts up
:something that will eat up sockbuf space and continuously fork, then we
:would lose all remote access to the machine in question (since all packets
:would be dropped) and we wouldn't really mind a panic() for obvious
:practical reasons.
:	In any case, I, personally, would prefer to suffer packet loss as
:opposed to a panic (especially now that Brian is in the process of writing
:diffs that will allow us to limit socket buffer space per UID through
:login.conf!)
:	Having MGET store that null (e.g. fail as opposed to panic) on a
:M_WAIT seems fairly easy to fix, and would probably require some patching
:that would ensure that the packet loss is handeled relatively 'cleanly'
:(probably some debugging), but I wouldn't mind doing this. However, I'd
:like to know if there are objections to doing this or, in fact, if there
:are any suggestions on how to handle mbuf shortage situations (aside from
:just limiting -- although limiting is in itself a good solution and I'm
:glad that Brian F. is working on that).
:
:Cheers,
:Bosko.

    The issue is basically having someone find the time to figure out
    how to gracefully unwind various pieces of network code when an
    mbuf cannot be allocated.  Once that is done, the panic can be
    turned into a (rate-limited) printf.

					-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909060418.VAA70623>