Re: panic: vputx: missed vn_close

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=<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

I've verified the scenario and are now testing with your patch.

- Peter