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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40E8385C.5000708>