cvs commit: src/sys/vm uma_core.c

[Scott Long]

Brian Fundakowski Feldman wrote:
> On Sun, Jul 04, 2004 at 03:59:25PM +0000, Brian Feldman wrote:
> 
>>green       2004-07-04 15:59:25 UTC
>>
>>  FreeBSD src repository
>>
>>  Modified files:
>>    sys/vm               uma_core.c 
>>  Log:
>>  Reextend the M_WAITOK-disabling-hack to all three of the mbuf-related
>>  zones, and do it by direct comparison of uma_zone_t instead of strcmp.
>>  
>>  The mbuf subsystem used to provide M_TRYWAIT/M_DONTWAIT semantics, but
>>  this is mostly no longer the case.  M_WAITOK has taken over the spot
>>  M_TRYWAIT used to have, and for mbuf things, still may return NULL if
>>  the code path is incorrectly holding a mutex going into mbuf allocation
>>  functions.
>>  
>>  The M_WAITOK/M_NOWAIT semantics are absolute; though it may deadlock
>>  the system to try to malloc or uma_zalloc something with a mutex held
>>  and M_WAITOK specified, it is absolutely required to not return NULL
>>  and will result in instability and/or security breaches otherwise.
>>  There is still room to add the WITNESS_WARN() to all cases so that
>>  we are notified of the possibility of deadlocks, but it cannot change
>>  the value of the "badness" variable and allow allocation to actually
>>  fail except for the specialized cases which used to be M_TRYWAIT.
> 
> 
> Any subsequent desire to change the semantics of malloc(9) or
> uma_zalloc(9) in the M_WAITOK case, such as this, absolutely must be
> taken up with the Security Officer.
> 

I'd like you to take this argument OUT of the cvs repository _NOW_ and
resolve it with the MBUMA and (optionally) UMA maintainers.  This
behaviour is totally unacceptable regardless of the technical merits.

Scott