From owner-freebsd-stable@FreeBSD.ORG Mon Jul 7 02:25:34 2003 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E00F637B428 for ; Mon, 7 Jul 2003 02:25:33 -0700 (PDT) Received: from smtp02.syd.iprimus.net.au (smtp02.syd.iprimus.net.au [210.50.76.52]) by mx1.FreeBSD.org (Postfix) with ESMTP id E246943F75 for ; Mon, 7 Jul 2003 02:25:32 -0700 (PDT) (envelope-from tim@robbins.dropbear.id.au) Received: from dilbert.robbins.dropbear.id.au (210.50.114.33) by smtp02.syd.iprimus.net.au (7.0.015) id 3EF7A10D002356A5; Mon, 7 Jul 2003 19:25:30 +1000 Received: by dilbert.robbins.dropbear.id.au (Postfix, from userid 1000) id 2177EC96E; Mon, 7 Jul 2003 19:25:28 +1000 (EST) Date: Mon, 7 Jul 2003 19:25:27 +1000 From: Tim Robbins To: "Marc G. Fournier" , freebsd-stable@freebsd.org, Ted Mittelstaedt Message-ID: <20030707192527.A9706@dilbert.robbins.dropbear.id.au> References: <20030701155450.J67063@hub.org> <20030702073306.GA3324@HAL9000.homeunix.com> <20030702084558.J67063@hub.org> <20030703033117.GA7647@HAL9000.homeunix.com> <20030703005047.B67063@hub.org> <20030707080530.GA23029@HAL9000.homeunix.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030707080530.GA23029@HAL9000.homeunix.com>; from das@freebsd.org on Mon, Jul 07, 2003 at 01:05:30AM -0700 Subject: Re: Okay, looks like I might have a *good* one here ... inode hang X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2003 09:25:34 -0000 On Mon, Jul 07, 2003 at 01:05:30AM -0700, David Schultz wrote: > On Thu, Jul 03, 2003, Marc G. Fournier wrote: > > > follow that one, too. Maybe the trail will simply lead back to > > > unionfs... > > > > 'K, how about a loop? > > Heh...it's a deadlock between unionfs and nullfs. Sheesh. > If unionfs is at fault here, I think I already know where > the problem is, and it isn't easy to fix. But I'll have to > look more carefully when I get a chance. nullfs on 4.x can probably deadlock in certain situations while attempting to recycle vnodes; see null_vnops.c 1.63. This bug was made more obvious in 5.x by null_vnops.c 1.51, but I'm pretty sure that the problem was still there in earlier versions, but was just harder to trigger. There are a few questionable things in unionfs too. There might be a race in union_inactive() (should it grab the vnode interlock before dropping the vnode lock and call vgonel() instead of vgone()?), and the support for locking stacks of vnodes seems to be #if 0'd out in union_lock(). Tim