Re: malloc(M_NOWAIT) issues.

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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
:> 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 
    programming IMHO.

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>