Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 04 Jul 2004 11:03:24 -0600
From:      Scott Long <scottl@samsco.org>
To:        Brian Fundakowski Feldman <green@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/vm uma_core.c
Message-ID:  <40E8385C.5000708@samsco.org>
In-Reply-To: <20040704160339.GA997@green.homeunix.org>
References:  <200407041559.i64FxPpj048980@repoman.freebsd.org> <20040704160339.GA997@green.homeunix.org>

index | next in thread | previous in thread | raw e-mail

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


home | help

Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40E8385C.5000708>