From owner-freebsd-stable@FreeBSD.ORG Mon Jul 7 22:49:40 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 4367A37B401; Mon, 7 Jul 2003 22:49:40 -0700 (PDT) Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [206.29.169.15]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4B23F43F85; Mon, 7 Jul 2003 22:49:39 -0700 (PDT) (envelope-from tedm@toybox.placo.com) Received: from tedsbox (nat-rtr.freebsd-corp-net-guide.com [206.29.168.154]) h685nbF47429; Mon, 7 Jul 2003 22:49:37 -0700 (PDT) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Tim Robbins" , "Marc G. Fournier" , Date: Mon, 7 Jul 2003 22:50:39 -0700 Message-ID: <000f01c34514$dc260ed0$1401a8c0@tedsbox> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 In-Reply-To: <20030707192527.A9706@dilbert.robbins.dropbear.id.au> Importance: Normal 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: Tue, 08 Jul 2003 05:49:40 -0000 Mark, Don't forget to attach this to the original PR's that you filed. Ted -----Original Message----- From: Tim Robbins [mailto:tjr@FreeBSD.ORG] Sent: Monday, July 07, 2003 2:25 AM To: Marc G. Fournier; freebsd-stable@FreeBSD.ORG; Ted Mittelstaedt Subject: Re: Okay, looks like I might have a *good* one here ... inode hang 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