DragonFly kernel List (threaded) for 2004-01
Re: malloc(M_NOWAIT) issues.
:I think that quite a few malloc(...M_NOWAIT) and mget(M_DONTWAIT...) are
:- in 5.x at least - subject to the following comment in mutex(9):
:> Sleeping while holding a mutex (except for Giant) is almost never safe
:> and should be avoided. There are numerous assertions which will fail if
:> this is attempted.
:with devastating results in most cases. WITNESS will even warn of
:malloc(...M_WAITOK) while holding a mutex.
:While this is something pretty 5.x specifc, I though I just report this as
:it really tasted wrong to me when I came across it for the first time
:(while doing pfil_hook locking for 5.x). But I found that you get used to
:malloc with M_NOWAIT whenever you even _might_ be holding a mutex.
:FWIW, mbuf(9) alloc functions need a redo with similar resoning. There are
:many places where a failed mget() will cause a panic.
:Best regards, | max@xxxxxxxxxxxxxx
:Max Laier | ICQ #67774661
Yes, that makes a lot of sense. I'll bet it started fairly benign but
then momentum built up as people were trying to get rid of mutex issues.
The result is pretty horrible, though. The very careful v_free_min and
v_interrupt_free_min settings were never designed to deal with the level
of M_NOWAIT use that currently exists in 5.x, and malloc's should never
be done inside mutexes anyway... it makes for extremely sloppy
I've been perusing the M_NOWAIT use in DFly and have come to the
conclusion that the vast majority of the M_NOWAIT useage could, in fact,
be implemented as a blocking wait.
I am going to start by cleaning up the M_ flags, making them more
flexible (but keeping equivalent operation for the most part), then
I'll start working on some of the worst pieces.