I updated my 6-CURRENT machine to today's source, and when I rebooted with the new kernel, I got this lock assertion failure: kern_symlink = 0 Trying to mount root from ufs:/dev/da0s1a kernel_vmount = 0 KDB: stack backtrace: vfs_badlock(c26f3ac8,c08eff00,c26f3ac8,0,c22854c0) at vfs_badlock+0x61 assert_vop_locked(c26f3ac8,c084ed5a,c26f3ac8,e32c4c20,c0676ad9) at assert_vop_lo cked+0x80 vop_unlock_pre(e32c4c08,c08ef780,c26f3ac8,10000,c2285450) at vop_unlock_pre+0x3c vput(c26f3ac8,c2285450,c247d620,c26f4000,c08ef780) at vput+0x89 vfs_mountroot_try(c26ad800,c084280d,204,c05fda98,c2284dc8) at vfs_mountroot_try+ 0x3ad vfs_mountroot(c2285450,c2284dc8,0,e32c4d14,c0632efa) at vfs_mountroot+0x1db start_init(0,e32c4d48,0,c05fda98,0) at start_init+0x4b fork_exit(c05fda98,0,e32c4d48) at fork_exit+0x7e fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe32c4d7c, ebp = 0 --- VOP_UNLOCK: 0xc26f3ac8 is not locked but should be KDB: enter: lock violation [thread pid 1 tid 100003 ] Stopped at kdb_enter+0x2c: leave db> My kernel is built with the DEBUG_VFS_LOCKS option. My November 22nd kernel doesn't have this problem. I'm guessing it is a bug in the recent mountroot changes. The vput() call is actually in devfs_fixup(): mp->mnt_vnodecovered = vp; vp->v_mountedhere = mp; mtx_lock(&mountlist_mtx); TAILQ_INSERT_TAIL(&mountlist, mp, mnt_list); mtx_unlock(&mountlist_mtx); VOP_UNLOCK(vp, 0, td); vfs_unbusy(mp, td); VREF(vp); ---> vput(vp); vput(dvp); vput() is supposed to be called with the vnode lock held and it releases the lock, which won't work too well because the vnode was just unlocked 3 lines earlier. vput() also decrements the vnode reference count, but why are we incrementing the reference count on the line above? I suspect that the VREF()/vput() sequence should just go away. In any case, if I just continue from the debugger, the system boots up normally.Received on Sun Dec 19 2004 - 06:32:35 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:24 UTC