cvs commit: src/sys/vm uma_core.c

[Bosko Milekic]

This is unfair.  I told you both in public and in private that
I didn't think this approach of segragating this behavior to mbuf
allocations was the right approach and even suggested what the right
approach should have been.  You asked me to review a change that
further segragated this behavior to mbuf allocations but then
committed the change 5 minutes later without giving me an
opportunity to reply.

What I've done is made the sysctl-introduction change myself and
committed it instead of this.

In the future I hope that you'll learn to be more patient and less
righteous when ordering others not to commit something before
going through the SO.

-Bosko


The commit log:

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.

  Revision  Changes    Path
  1.99      +4 -2      src/sys/vm/uma_core.c