malloc(M_WAITOK) of"Mbuf",forcing M_NOWAIT ......
Bosko Milekic
bmilekic at FreeBSD.org
Tue Jun 1 13:58:30 PDT 2004
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 @
More information about the freebsd-current
mailing list