Re: panic: vputx: missed vn_close

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=<value optimized out>, ap=<value
> optimized out>) at
> /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:753
> #3  0xffffffff804c4e56 in kassert_panic (fmt=<value optimized out>) 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=<value optimized out>) at
> /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:743
> #6  0xffffffff8070aee8 in VOP_RECLAIM_APV (vop=<value optimized out>,
> a=<value optimized out>) 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=<value optimized out>)
>     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=<value optimized out>) 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
+++ b/sys/fs/nullfs/null_vnops.c
_at__at_ -740,6 +740,13 _at__at_ null_reclaim(struct vop_reclaim_args *ap)
 	vp->v_object = NULL;
 	vp->v_vnlock = &vp->v_lock;
 	VI_UNLOCK(vp);
+
+	/*
+	 * If we were opened for write, we borrowed one write
+	 * reference to the lower vnode.  Undo the reference now.
+	 */
+	if (vp->v_writecount > 0)
+		VOP_ADD_WRITECOUNT(lowervp, -1);
 	vput(lowervp);
 	free(xp, M_NULLFSNODE);