On Wed, Nov 01, 2006 at 11:57:48AM +0100, Ulrich Spoerlein wrote: > On 10/31/06, Kris Kennaway <[EMAIL PROTECTED]> wrote: > >Note that they'll be demand-loaded if requested (e.g. if you try to > >mount_nullfs). Maybe you or something else tried to mount such a > >filesystem by accident? > > > >> But the point is mood anyway, since I could not reproduce the problem. > >> I tried again after rebooting the machine and everything went just > >> fine ... > >> > >> I have to use the nullfs mounts on another machine shortly, let's see > >> what happens there. > > It reliably paniced in single user mode, with no other modules loaded > at the time. But, I see now that nullfs.ko is loaded as a module, > which might explain everything. I assumed it was built in. > > I rebooted to a kernel without DEBUG_VFS_LOCKS and it's happily using > nullfs. I'll try once more with a debugging kernel, that has nullfs > built in, but I'll guess the panic vanishes. > > > Ok, with the attached kernel config, which includes nullfs, I get a > duplicate lock, instead of a panic > Trying to mount root from ufs:/dev/da0s1a > acquiring duplicate lock of same type: "vnode interlock" > 1st vnode interlock @ /usr/src/sys/kern/vfs_vnops.c:806 > 2nd vnode interlock @ /usr/src/sys/kern/vfs_subr.c:2036 > KDB: stack backtrace: > kdb_backtrace(3,c894fa80,c0a47110,c0a47110,c09cb524,...) at > kdb_backtrace+0x29 > witness_checkorder(c8622d04,9,c0951b38,7f4) at witness_checkorder+0x578 > _mtx_lock_flags(c8622d04,0,c0951b38,7f4,c840b590,...) at > _mtx_lock_flags+0x78 > vrefcnt(c8622c3c) at vrefcnt+0x20 > null_checkvp(c8a7ed98,c093f5ae,215) at null_checkvp+0x56 > null_lock(eb0bba80) at null_lock+0x66 > VOP_LOCK_APV(c09c40a0,eb0bba80) at VOP_LOCK_APV+0x87 > vn_lock(c8a7ed98,1002,c894fa80,c8a7ed98,c8a89224,...) at vn_lock+0xac > nullfs_root(c88052e4,2,eb0bbaf8,c894fa80,0,8,0,c0a84040,0,c09513da,3dd) > at nullfs_root+0x26 > vfs_domount(c894fa80,c83e64c0,c8493490,0,c83fdad0,c0a38380,0,c09513da,2a3) > at vfs_domount+0x975 > vfs_donmount(c894fa80,0,c87f4e00,c87f4e00,0,...) at vfs_donmount+0x2ef > nmount(c894fa80,eb0bbd04) at nmount+0x8b > syscall(3b,3b,3b,bfbfe435,bfbfecc8,...) at syscall+0x25b > Xint0x80_syscall() at Xint0x80_syscall+0x1f > --- syscall (378, FreeBSD ELF32, nmount), eip = 0x280ba4d7, esp = > 0xbfbfe3fc, ebp = 0xbfbfec78 --- > This is purely cosmetic, and shall make no harm. It is caused by debugging check. Just ignore it, or use the following to silence WITNESS:
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 1 Nov 2006 11:32:48 -0000 @@ -284,6 +284,8 @@ int lno; { struct null_node *a = VTONULL(vp); + struct vnode *lvp; + int refcnt; #ifdef notyet /* * Can't do this check because vop_reclaim runs @@ -295,7 +297,8 @@ panic("null_checkvp"); }; #endif - if (a->null_lowervp == NULLVP) { + lvp = a->null_lowervp; + if (lvp == NULLVP) { /* Should never happen */ int i; u_long *p; printf("vp = %p, ZERO ptr\n", (void *)vp); @@ -306,7 +309,10 @@ while (null_checkvp_barrier) /*WAIT*/ ; panic("null_checkvp"); } - if (vrefcnt(a->null_lowervp) < 1) { + VI_LOCK_FLAGS(lvp, MTX_DUPOK); + refcnt = lvp->v_usecount; + VI_UNLOCK(lvp); + if (refcnt < 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++) @@ -322,6 +328,6 @@ a->null_lowervp, vrefcnt(a->null_lowervp), fil, lno); #endif - return a->null_lowervp; + return lvp; } #endif
pgpAy23CuXv4D.pgp
Description: PGP signature