Date: Tue, 1 Jun 2004 13:58:30 -0700 From: Bosko Milekic <bmilekic@FreeBSD.org> To: Niki Denev <nike_d@cytexbg.com> Cc: current@freebsd.org Subject: Re: malloc(M_WAITOK) of"Mbuf",forcing M_NOWAIT ...... Message-ID: <20040601205830.GA119@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 @
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040601205830.GA119>