cvs commit: src/sys/vm uma_core.c
scottl at samsco.org
Sun Jul 4 10:03:43 PDT 2004
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
>> 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
>> 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.
More information about the cvs-all