<<On Wed, 12 May 1999 17:25:44 +0200, Pierre Beyssac <beys...@enst.fr> said:

> Another big problem is that there's a check in m_retry and friends
> that panics when falling short of mbufs! I really believe this does
> more harm than good, because it prevents correct calling code
> (checking for NULL mbuf pointers) from exiting gracefully with
> ENOBUFS...

I think we need to think a bit more about the right semantics before
making such a change.  M_WAIT is supposed to mean `I am in process
context and don't mind sleeping in order to get an mbuf, but there is
too much locking going on inside the network stack to be able to
safely sleep without serious risk of deadlock.

This is the sort of application which would be ideal for Matt's
`asleep' interface.  Then, the code could back its way out of any
locks and spls, safely wait for sufficient mbufs to be freed, and then
retry.  Even then, it's still possible to deadlock if one process hogs
the entire mbuf pool.  It may be necessary to incrementally penalize
processes which do so.

FWIW, the 4.3 code sleeps in a loop.

-GAWollman

--
Garrett A. Wollman   | O Siem / We are all family / O Siem / We're all the same
woll...@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


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Reply via email to