From owner-freebsd-current@FreeBSD.ORG Thu Jan 10 09:09:15 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B0076311 for ; Thu, 10 Jan 2013 09:09:15 +0000 (UTC) (envelope-from pho@holm.cc) Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by mx1.freebsd.org (Postfix) with SMTP id 5ECF7EDE for ; Thu, 10 Jan 2013 09:09:14 +0000 (UTC) Received: (qmail 86217 invoked from network); 10 Jan 2013 09:02:32 -0000 Received: from 87.58.146.155 (HELO x2.osted.lan) (87.58.146.155) by relay01.pair.com with SMTP; 10 Jan 2013 09:02:32 -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 r0A92VXe001810; Thu, 10 Jan 2013 10:02:31 +0100 (CET) (envelope-from pho@x2.osted.lan) Received: (from pho@localhost) by x2.osted.lan (8.14.5/8.14.5/Submit) id r0A92VJi001809; Thu, 10 Jan 2013 10:02:31 +0100 (CET) (envelope-from pho) Date: Thu, 10 Jan 2013 10:02:31 +0100 From: Peter Holm To: Konstantin Belousov Subject: Re: panic: vputx: missed vn_close Message-ID: <20130110090231.GA1746@x2.osted.lan> References: <50EDBC7B.5070408@smeets.im> <20130109234007.GJ2561@kib.kiev.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130109234007.GJ2561@kib.kiev.ua> User-Agent: Mutt/1.4.2.3i Cc: "current@freebsd.org" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 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, 10 Jan 2013 09:09:15 -0000 On Thu, Jan 10, 2013 at 01:40:07AM +0200, Konstantin Belousov wrote: > On Wed, Jan 09, 2013 at 07:52:43PM +0100, Florian Smeets wrote: > > Hi, > > > > I got this while building packages with poudriere. I'm running r245188. > > > > Let me know if you need anything else from the dump. > > > > Florian > > > > VNASSERT failed > > 0xfffffe04fda5bba0: tag zfs, type VREG > > usecount 1, writecount 1, refcount 1 mountedhere 0 > > flags (VI_ACTIVE) > > VI_LOCKed v_object 0xfffffe062f6479f8 ref 0 pages 0 > > lock type zfs: EXCL by thread 0xfffffe00bd683480 (pid 34602, umount, > > tid 100578) > > panic: vputx: missed vn_close > > cpuid = 3 > > Uptime: 9h25m23s > > Dumping 13255 out of 32647 > > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% > > > > [...] > > > > (kgdb) where > > #0 doadump (textdump=1) at pcpu.h:229 > > #1 0xffffffff804c4ab7 in kern_reboot (howto=260) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:446 > > #2 0xffffffff804c4fc6 in vpanic (fmt=, ap= > optimized out>) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:753 > > #3 0xffffffff804c4e56 in kassert_panic (fmt=) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:641 > > #4 0xffffffff8055714d in vputx (vp=0xfffffe04fda5bba0, func=2) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2243 > > #5 0xffffffff80d6b42f in null_reclaim (ap=) at > > /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:743 > > #6 0xffffffff8070aee8 in VOP_RECLAIM_APV (vop=, > > a=) at vnode_if.c:1959 > > #7 0xffffffff8055844c in vgonel (vp=0xfffffe04fda5b7c0) at vnode_if.h:830 > > #8 0xffffffff80557a7f in vflush (mp=0xfffffe0533ce3cc0, rootrefs=1, > > flags=2, td=0xfffffe00bd683480) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2625 > > #9 0xffffffff80d6aa4e in nullfs_unmount (mp=0xfffffe0533ce3cc0, > > mntflags=) > > at > > /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/null_vfsops.c:250 > > #10 0xffffffff805502cf in dounmount (mp=0xfffffe0533ce3cc0, > > flags=134742016, td=) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1314 > > #11 0xffffffff8054ff8b in sys_unmount (td=0xfffffe00bd683480, > > uap=0xffffff90d2c87a40) at > > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1211 > > #12 0xffffffff806b4845 in amd64_syscall (td=0xfffffe00bd683480, > > traced=0) at subr_syscall.c:134 > > #13 0xffffffff8069d04b in Xfast_syscall () at exception.S:387 > > #14 0x0000000800882ffa in ?? () > > Previous frame inner to this frame (corrupt stack?) > > > > I was able to reproduce it locally. I think that you need to have a file > opened for write on the nullfs mount, and then do forced unmount of > the mount, while file is still open. > > The patch below fixed it for me. > > diff --git a/sys/fs/nullfs/null_vnops.c b/sys/fs/nullfs/null_vnops.c > index cc35d81..3be7366 100644 > --- a/sys/fs/nullfs/null_vnops.c I've verified the scenario and are now testing with your patch. - Peter