Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 4 Jul 2004 04:20:27 +0000
From:      Bosko Milekic <bmilekic@FreeBSD.org>
To:        Brian Feldman <green@FreeBSD.org>
Cc:        cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/vm uma_core.c
Message-ID:  <20040704042027.GA94373@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

  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@cicely5.cicely.de>
>
>  Revision  Changes    Path
>  1.98      +8 -4      src/sys/vm/uma_core.c



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