vnode lock assertion violation in devfs_fixup()

From: Don Lewis <truckman_at_FreeBSD.org>
Date: Sat, 18 Dec 2004 23:32:28 -0800 (PST)
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