From owner-freebsd-stable@FreeBSD.ORG Thu May 9 07:03:06 2013 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 17EAA6DE for ; Thu, 9 May 2013 07:03:06 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by mx1.freebsd.org (Postfix) with SMTP id C9080353 for ; Thu, 9 May 2013 07:03:05 +0000 (UTC) Received: (qmail 15317 invoked from network); 9 May 2013 07:02:58 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay02.pair.com with SMTP; 9 May 2013 07:02:58 -0000 X-pair-Authenticated: 87.58.146.155 Received: from x2.osted.lan (localhost [127.0.0.1]) by x2.osted.lan (8.14.5/8.14.5) with ESMTP id r4972vDA015984; Thu, 9 May 2013 09:02:57 +0200 (CEST) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r4972vw2015983; Thu, 9 May 2013 09:02:57 +0200 (CEST) (envelope-from pho) Date: Thu, 9 May 2013 09:02:56 +0200 From: Peter Holm To: Konstantin Belousov Subject: Re: Nullfs leaks i-nodes Message-ID: <20130509070256.GA15884@x2.osted.lan> References: <20130508091317.GJ3047@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130508091317.GJ3047@kib.kiev.ua> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-stable@freebsd.org X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 May 2013 07:03:06 -0000 On Wed, May 08, 2013 at 12:13:17PM +0300, Konstantin Belousov wrote: > On Tue, May 07, 2013 at 08:30:06AM +0200, G??ran L??wkrantz wrote: > > I created a PR, kern/178238, on this but would like to know if anyone has > > any ideas or patches? > > > > Have updated the system where I see this to FreeBSD 9.1-STABLE #0 r250229 > > and still have the problem. > > The patch below should fix the issue for you, at least it did so in my > limited testing. > > What is does: > 1. When inactivating a nullfs vnode, check if the lower vnode is > unlinked, and reclaim upper vnode if so. [This fixes your case]. > > 2. Besides a callback to the upper filesystems for the lower vnode > reclaimation, it also calls the upper fs for lower vnode unlink. > This allows nullfs to purge cached vnodes for the unlinked lower. > [This fixes an opposite case, when the vnode is removed from the > lower mount, but upper aliases prevent the vnode from being > recycled]. > > 3. Fix a wart which existed from the introduction of the nullfs caching, > do not unlock lower vnode in the nullfs_reclaim_lowervp(). It should > be completely innocent, but now it is also formally safe. > > 4. Fix vnode reference leak in nullfs_reclaim_lowervp(). > > Please note that the patch is basically not tested, I only verified your > scenario and a mirror of it as described in item 2. > > diff --git a/sys/fs/nullfs/null.h b/sys/fs/nullfs/null.h > index 4f37020..a624be6 100644 > --- a/sys/fs/nullfs/null.h The page fault seen in fifo_close() seems unrelated to this patch, which I will continue testing some more. The scenario triggering the page fault is the "rm": mdconfig -a -t swap -s 1g -u 5 bsdlabel -w md5 auto newfs -U md5a mount /dev/md5a /mnt mount -t nullfs /mnt /mnt2 mkfifo /mnt2/fifo rm /mnt/fifo Not a problem on 8.3-STABLE r247938. - Peter