Re: malloc(M_WAITOK) of"Mbuf",forcing M_NOWAIT ......

  I've exposed these with the recent mbuma changes, but they are
  more general problems in the network code, so here is the
  explanation, for the record.

  We have some code paths in the network code that lead to
  en eventual Mbuf or Cluster allocation occuring with
  M_WAITOK, but where locks other than Giant are held.  This
  is illegal as it may lead to deadlock in certain cases (LOR
  with Giant) and just plain shitty performance in others
  (lock held for long periods of time).

  In particular, the codepath you post below is probably easily
  reproduced by turning on WITNESS in recent -CURRENT (with
  mbuma) and issuing 'ping -s 65000 127.0.0.1'.  Some others
  are more difficult to catch, so I urge those doing the
  catching to post the traces, if different from those already
  seen, so that we can fix them.

  The current interim solution, which I committed with mbuma,
  forces all UMA allocations for the moment to occur with
  M_NOWAIT unless WITNESS is available and we know for a fact
  that we're not holding any locks other than Giant.  This is
  not a permanent solution.

-Bosko

You wrote:
>I get lots of these messages on my console with a recent -CURRENT,
>is this something known?
>
>----------------------------------------------------------------
>malloc(M_WAITOK) of "Mbuf", forcing M_NOWAIT with the following
>non-sleepable locks held:
>exclusive sleep mutex inp (rawinp) r = 0 (0xc2076090) locked _at_