Date: Mon, 13 Sep 1999 13:17:56 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: Bosko Milekic <bmilekic@dsuper.net>, Stas Kisel <stas@sonet.crimea.ua>, avalon@coombs.anu.edu.au, freebsd-hackers@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: mbuf shortage situations (followup) Message-ID: <199909132017.NAA25509@apollo.backplane.com> References: <199909091447.SAA24055@sonet.crimea.ua> <Pine.OSF.4.05.9909122304470.18795-300000@oracle.dsuper.net> <199909131840.OAA31048@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
: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.
:
:-GAWollman
:
:--
:Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same
This is an interrupt level mechanism. The mbuf code is *already* allowed
to (and does) return NULL in this case so I don't think it applies to
the problem under discussion.
The case that is causing the panics is with the non-interrupt mbuf
allocation mechanism. Specifically, the case where M_WAIT is used.
The second problem under discussion, which really ought to be separated
out from the mbuf panic problem, is the potential for a deadlock or
denial of service attack when the system is attacked in a manner that
eats all available mbufs.
:wollman@lcs.mit.edu | O Siem / The fires of freedom
:Opinions not those of| Dance in the burning flame
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199909132017.NAA25509>