From owner-freebsd-current@FreeBSD.ORG Wed May 28 12:04:34 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 0105137B401; Wed, 28 May 2003 12:04:34 -0700 (PDT) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0840243F3F; Wed, 28 May 2003 12:04:31 -0700 (PDT) (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 h4SJ4Q29001924 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 28 May 2003 15:04:26 -0400 (EDT) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.11.6/8.9.1) id h4SJ4Ks33882; Wed, 28 May 2003 15:04:20 -0400 (EDT) (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: <16085.2100.902452.819504@grasshopper.cs.duke.edu> Date: Wed, 28 May 2003 15:04:20 -0400 (EDT) To: David Malone In-Reply-To: <200305281628.aa67444@salmon.maths.tcd.ie> References: <200305281628.aa67444@salmon.maths.tcd.ie> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid cc: Robert Watson cc: current@FreeBSD.org Subject: Re: mb alloc and: panic: mutex Giant not owned at ../../../vm/vm_kern.c:315 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: Wed, 28 May 2003 19:04:34 -0000 David Malone writes: > > > This may be my fault, as I made some changes recently that assumed that > > > the mbuf allocator grabbed giant when needed. I'll check the code path > > > you've mentioned to see if it grabs giant now, but I suspect that I just > > > need to move the giant grabbing back where it was before. > > > This doesn't seem to be a reproduceable problem for me, FWIW, (presumably > > a property of bucket sizes, etc) so you have all the information I have > > :-). > > You'd have to be quite unlucky to trigger it (calling sendit at a > time when a per-cpu mbuf pool was empty). I have a vague feeling > that my sendit change isn't the only place that does this. FWIW, calling kmem_malloc() w/o Giant is safe if you call with NOWAIT. But if you wait, you must hold Giant. Drew