Re: panic: vputx: missed vn_close

看板FB_current作者時間12年前 (2013/04/27 13:01), 編輯推噓0(000)
留言0則, 0人參與, 最新討論串3/3 (看更多)
--Ublo+h3cBgJ33ahC Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Jan 09, 2013 at 07:52:43PM +0100, Florian Smeets wrote: > Hi, >=20 > I got this while building packages with poudriere. I'm running r245188. >=20 > Let me know if you need anything else from the dump. >=20 > Florian >=20 > 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 =3D 3 > Uptime: 9h25m23s > Dumping 13255 out of 32647 > MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91% >=20 > [...] >=20 > (kgdb) where > #0 doadump (textdump=3D1) at pcpu.h:229 > #1 0xffffffff804c4ab7 in kern_reboot (howto=3D260) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:446 > #2 0xffffffff804c4fc6 in vpanic (fmt=3D<value optimized out>, ap=3D<value > optimized out>) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:753 > #3 0xffffffff804c4e56 in kassert_panic (fmt=3D<value optimized out>) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/kern_shutdown.c:641 > #4 0xffffffff8055714d in vputx (vp=3D0xfffffe04fda5bba0, func=3D2) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2243 > #5 0xffffffff80d6b42f in null_reclaim (ap=3D<value optimized out>) at > /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/nu= ll_vnops.c:743 > #6 0xffffffff8070aee8 in VOP_RECLAIM_APV (vop=3D<value optimized out>, > a=3D<value optimized out>) at vnode_if.c:1959 > #7 0xffffffff8055844c in vgonel (vp=3D0xfffffe04fda5b7c0) at vnode_if.h:= 830 > #8 0xffffffff80557a7f in vflush (mp=3D0xfffffe0533ce3cc0, rootrefs=3D1, > flags=3D2, td=3D0xfffffe00bd683480) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_subr.c:2625 > #9 0xffffffff80d6aa4e in nullfs_unmount (mp=3D0xfffffe0533ce3cc0, > mntflags=3D<value optimized out>) > at > /usr/home/flo/dev/checkouts/svn-src/sys/modules/nullfs/../../fs/nullfs/nu= ll_vfsops.c:250 > #10 0xffffffff805502cf in dounmount (mp=3D0xfffffe0533ce3cc0, > flags=3D134742016, td=3D<value optimized out>) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1314 > #11 0xffffffff8054ff8b in sys_unmount (td=3D0xfffffe00bd683480, > uap=3D0xffffff90d2c87a40) at > /usr/home/flo/dev/checkouts/svn-src/sys/kern/vfs_mount.c:1211 > #12 0xffffffff806b4845 in amd64_syscall (td=3D0xfffffe00bd683480, > traced=3D0) 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?) >=20 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 @@ -740,6 +740,13 @@ null_reclaim(struct vop_reclaim_args *ap) vp->v_object =3D NULL; vp->v_vnlock =3D &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); =20 --Ublo+h3cBgJ33ahC Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ7f/WAAoJEJDCuSvBvK1BFgAP/23/mb2Zgdn1dJwgwGSY6e2E UN2Gsw4mclgJgciSBzWwD/RbNKAu0NrlUTc76TMPqbfM4tp7QCKL7keH+m1u48e3 h2kQhmkazWskWy9rtNp796LOB3dESEkipLy4cQctkNDFlx/QjoDNP8CcZagpctjZ wGrQVLsoOwOuLF45XmoG31XULer93pZaQFQke71af3gW6yGSkOpQzzQMtlwxIHXJ boPHQCQBnKGBbc9d0kRX8uFjW3dwxONkaN179bMSFlIw2NBs0c11WvtWLUiQQFBU +PSC+Sh/tSusDj9oBz4jD5Kftx0z3WJVWOUcx2ZPzlAAPHaJAkr99ggEnpea94XD RUEL45oG+y0V8TzITpWaM4ybwzXl8B9DQYCa5U8PIzl1OlqhDecjFgyKQY0y9k22 r1eCw65LHjebt7dk9jAcGK7AP/DTDYsSIU1xqw+NyM8kzOGaxNWjSEIE5vl3EOon XLuVDo8eak5gqkfoTMdTxgQ2clcMUGBuDar0Pfnz2EIXMTjCM3sz2xKXGFfonauP zOU88l5g5mQ84GWjcwaYtvuWl5ukhMNlnyVWN1QOWNfZBmJUaz1SHkoRnEclP9sY /p7CfQLwT965UkbN859aB6OuV6TvRgZjQJWNScymZcjySUd22rVUo/qz2oY5B+39 iruVs8zGvZ99xS+YK2Ow =xe7n -----END PGP SIGNATURE----- --Ublo+h3cBgJ33ahC--
文章代碼(AID): #1HUrkrpG (FB_current)
文章代碼(AID): #1HUrkrpG (FB_current)