This change is bogus. It checks uz_name against "Mbuf" but mbuma also
defines a "Packet" zone.
Even if that were fixed, I would personally prefer a backout. The
original intent of this [temporary] piece of code is to help detect
potential deadlocks and make sure that they don't happen, as they are
generally tougher to debug than traps on NULL pointer dereferences.
The fact that without WITNESS M_WAITOK is actually overriden by
M_NOWAIT behavior, although conservative, ensures that deadlock due
to, say, locks being held while sleeping.
The need for the temporary code is still significant because we still
have code paths that could potentially lead to deadlock here. I'd
rather proactively, albeit conservatively, avoid that deadlock, knowing
that the situation where even M_NOWAIT will return NULL should not
occur unless I have heavy/unexpected load anyway.
With that said, I would agree to you adding a way to have badness on
0 by default, possibly by making it a debug boot-time tunable, or
Brian Feldman wrote:
>green 2004-07-03 18:11:41 UTC
> FreeBSD src repository
> Modified files:
> sys/vm uma_core.c
> Limit mbuma damage. Suddenly ALL allocations with M_WAITOK are subject
> to failing -- that is, allocations via malloc(M_WAITOK) that are required
> to never fail -- if WITNESS is not defined. While everyone should be
> running WITNESS, in any case, zone "Mbuf" allocations are really the only
> ones that should be screwed with by this hack.
> This hack is crashing people, and would continue to do so with or without
> WITNESS. Things shouldn't be allocating with M_WAITOK with locks held,
> but it's not okay just to always remove M_WAITOK when !WITNESS.
> Reported by: Bernd Walter <firstname.lastname@example.org>
> Revision Changes Path
> 1.98 +8 -4 src/sys/vm/uma_core.c