freebsd stable - Mar 2006 - acquiring duplicate lock of same type: "vnode interlock"

I think I've read somewhere about panic during early root mount, fsck
etc.. Perhaps this might be related:

Full dmesg: http://people.freebsd.org/~ariff/misc/dmesg.boot.amd64

[....]
acquiring duplicate lock of same type: "vnode interlock"
 1st vnode interlock @ kern/vfs_vnops.c:791
 2nd vnode interlock @ kern/vfs_subr.c:2018
KDB: stack backtrace:
witness_checkorder() at witness_checkorder+0x4da
_mtx_lock_flags() at _mtx_lock_flags+0x4a
vrefcnt() at vrefcnt+0x31
null_checkvp() at null_checkvp+0x65
null_lock() at null_lock+0x5b
VOP_LOCK_APV() at VOP_LOCK_APV+0x81
vn_lock() at vn_lock+0x6b
nullfs_root() at nullfs_root+0x4c
vfs_donmount() at vfs_donmount+0x1096
nmount() at nmount+0x82
syscall() at syscall+0x21b
Xfast_syscall() at Xfast_syscall+0xa8
--- syscall (378, FreeBSD ELF64, nmount), rip = 0x800679e8c, rsp 0x7fffffffe558,
rbp = 0x7fffffffee40 ---


--
Ariff Abdullah
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060317/8da84f4a/attachment-0001.pgp

On Fri, Mar 17, 2006 at 06:51:42PM +0800, Ariff Abdullah
wrote:
> I think I've read somewhere about panic during early root mount, fsck
> etc.. Perhaps this might be related:
> 
> Full dmesg: http://people.freebsd.org/~ariff/misc/dmesg.boot.amd64
> 
> [....]
> acquiring duplicate lock of same type: "vnode interlock"
>  1st vnode interlock @ kern/vfs_vnops.c:791
>  2nd vnode interlock @ kern/vfs_subr.c:2018
> KDB: stack backtrace:
> witness_checkorder() at witness_checkorder+0x4da
> _mtx_lock_flags() at _mtx_lock_flags+0x4a
> vrefcnt() at vrefcnt+0x31
> null_checkvp() at null_checkvp+0x65
> null_lock() at null_lock+0x5b
> VOP_LOCK_APV() at VOP_LOCK_APV+0x81
> vn_lock() at vn_lock+0x6b
> nullfs_root() at nullfs_root+0x4c
> vfs_donmount() at vfs_donmount+0x1096
> nmount() at nmount+0x82
> syscall() at syscall+0x21b
> Xfast_syscall() at Xfast_syscall+0xa8
> --- syscall (378, FreeBSD ELF64, nmount), rip = 0x800679e8c, rsp >
0x7fffffffe558, rbp = 0x7fffffffee40 ---
It does not seem to be the moment of mounting root. Do you have
nullfs mounts in fstab ? If yes, then, probably, some user-mode
output is absent in your trace.

Anyway, issue looks like cosmetic
and manifests itself only under both WITNESS and DIAGNOSTIC options,
living itself in diagonstic code.

The patch shuts the witness in dirty manner:

Index: sys/fs/nullfs/null_subr.c
==================================================================RCS file:
/usr/local/arch/ncvs/src/sys/fs/nullfs/null_subr.c,v
retrieving revision 1.50
diff -u -r1.50 null_subr.c
--- sys/fs/nullfs/null_subr.c	22 Feb 2006 06:15:12 -0000	1.50
+++ sys/fs/nullfs/null_subr.c	17 Mar 2006 12:13:46 -0000
@@ -306,7 +306,7 @@
 		while (null_checkvp_barrier) /*WAIT*/ ;
 		panic("null_checkvp");
 	}
-	if (vrefcnt(a->null_lowervp) < 1) {
+ 	if (a->null_lowervp->v_usecount < 1) {
 		int i; u_long *p;
 		printf("vp = %p, unref'ed lowervp\n", (void *)vp);
 		for (p = (u_long *) a, i = 0; i < 8; i++)


I do not think that it worthy to reorg code to allow
to use vrefcnt.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20060317/36d1ac5d/attachment.pgp