Date: Sun, 5 Sep 1999 23:33:06 -0400 (EDT) From: Bosko Milekic <bmilekic@dsuper.net> To: freebsd-hackers@freebsd.org Cc: freebsd-security@freebsd.org Subject: mbuf shortage situations Message-ID: <Pine.OSF.4.05.9909052312260.25081-100000@oracle.dsuper.net>
next in thread | raw e-mail | index | archive | help
This post is somewhat in relation to the "local DoS" thread started on --security a few days ago. To slightly put things back into context: The panic() signaling "out of mbuf clusters" is a result of the initial MGET failing, calling m_retry, and failing again. Since we seem to be okay with waiting (e.g.: M_WAIT), and we fail in getting an mbuf cluster, m_retry panic()s. As far as what I've understood from glancing at some OpenBSD and NetBSD code, I'm pretty sure that they both handle this situation the same way we handle it if the m_retry is called with M_DONTWAIT, which is to return null to MGET, which would consequently set the mbuf structure pointer (in this case, struct mbuf *m) to null. This would probably result in packet loss. 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. /* * Bosko Milekic <bmilekic@dsuper.net> http://www.dsuper.net/~bmilekic/ * "A method of solution is perfect if we can foresee from the start, and * even prove, that by following that method we shall obtain our aim." */ 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.9909052312260.25081-100000>