cvs commit: src/sys/vm uma_core.c

Bosko Milekic bmilekic at FreeBSD.org
Sat Jul 3 21:20:27 PDT 2004


  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
  better, rw-sysctl.

-Bosko

Brian Feldman wrote:
>green       2004-07-03 18:11:41 UTC
>
>  FreeBSD src repository
>
>  Modified files:
>    sys/vm               uma_core.c
>  Log:
>  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 <ticso at cicely5.cicely.de>
>
>  Revision  Changes    Path
>  1.98      +8 -4      src/sys/vm/uma_core.c



More information about the cvs-src mailing list