From owner-freebsd-current@FreeBSD.ORG Thu Apr 3 10:36:14 2003 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 6D23737B401 for ; Thu, 3 Apr 2003 10:36:13 -0800 (PST) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8A84A43F75 for ; Thu, 3 Apr 2003 10:36:12 -0800 (PST) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.12.9/8.12.9) with ESMTP id h33IaBMS029205 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Apr 2003 13:36:11 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h33Ia6A32496; Thu, 3 Apr 2003 13:36:06 -0500 (EST) (envelope-from gallatin@cs.duke.edu) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16012.32534.331966.216694@grasshopper.cs.duke.edu> Date: Thu, 3 Apr 2003 13:36:06 -0500 (EST) To: Nate Lawson In-Reply-To: References: X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: current@freebsd.org Subject: Re: mbuf LOR 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: Thu, 03 Apr 2003 18:36:14 -0000 Nate Lawson writes: > I was testing some changes to make fxp MPSAFE and got a LOR in allocating > the mbuf cluster and then finally a panic when trying to dereference the > cluster header. Is the mbuf system MPSAFE? Is it ok to call m_getcl > with a device lock held (but not Giant)? > > The lock reversal was: 1. fxp softc lock, 2. Giant. > > Traceback: > zalloc... > malloc() > mb_pop_cont() > mb_alloc() > m_getcl() > fxp_add_rfabuf() > fxp_intr_body() > fxp_intr() -- locks fxp softc > > -Nate I think the only place it can be coming from is slab_zalloc(). Does the appended (untested) patch help? BTW, I don't think that there is any need to get Giant for the zone allocators in the M_NOWAIT case, but I'm not really familar with the code, and I don't know if the sparc64 uma_small_alloc needs Giant. BTW, my MPSAFE driver never sees this, but then again, I never allocate clusters. I use jumbo frames, and carve out my own recv buffers, so I'm only allocating mbufs, not clusters. Drew Index: uma_core.c =================================================================== RCS file: /home/ncvs/src/sys/vm/uma_core.c,v retrieving revision 1.51 diff -u -r1.51 uma_core.c --- uma_core.c 26 Mar 2003 18:44:53 -0000 1.51 +++ uma_core.c 3 Apr 2003 18:22:14 -0000 @@ -703,10 +703,14 @@ wait &= ~M_ZERO; if (booted || (zone->uz_flags & UMA_ZFLAG_PRIVALLOC)) { - mtx_lock(&Giant); - mem = zone->uz_allocf(zone, - zone->uz_ppera * UMA_SLAB_SIZE, &flags, wait); - mtx_unlock(&Giant); + if ((wait & M_NOWAIT) == 0) { + mtx_lock(&Giant); + mem = zone->uz_allocf(zone, + zone->uz_ppera * UMA_SLAB_SIZE, &flags, wait); + mtx_unlock(&Giant); + } else { + mem = NULL; + } if (mem == NULL) { ZONE_LOCK(zone); return (NULL);