From owner-freebsd-current@FreeBSD.ORG Tue Jun 1 13:58:30 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D654E16A4CE for ; Tue, 1 Jun 2004 13:58:30 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id D1BC043D55; Tue, 1 Jun 2004 13:58:30 -0700 (PDT) (envelope-from bmilekic@FreeBSD.org) Received: from freefall.freebsd.org (bmilekic@localhost [127.0.0.1]) i51KwU6m000215; Tue, 1 Jun 2004 13:58:30 -0700 (PDT) (envelope-from bmilekic@freefall.freebsd.org) Received: (from bmilekic@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i51KwUdp000214; Tue, 1 Jun 2004 13:58:30 -0700 (PDT) (envelope-from bmilekic) Date: Tue, 1 Jun 2004 13:58:30 -0700 From: Bosko Milekic To: Niki Denev Message-ID: <20040601205830.GA119@freefall.freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.1i cc: current@freebsd.org Subject: Re: malloc(M_WAITOK) of"Mbuf",forcing M_NOWAIT ...... X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Jun 2004 20:58:30 -0000 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 @