Lock Order Reversal in nmount/unmount of devfs on NFS

Linda Messerschmidt linda.messerschmidt at gmail.com
Fri Oct 22 18:17:55 UTC 2010


When mounting a devfs filesystem on top of a directory in an NFS
filesystem under 8.1-RELEASE-p1 r213075M, the following lock order
reversal is reported:

lock order reversal:
 1st 0xc264bbdc nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1058
 2nd 0xc264bce8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2090
KDB: stack backtrace:
X_db_sym_numargs(c032f02b,d58f6810,c0108c55,c00f906b,c0331eb2,...) at
X_db_sym_numargs+0x146
kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdd08,d58f686c,...) at
kdb_backtrace+0x29
witness_display_spinlock(c0331eb2,c264bce8,c0321549,c22bdd08,c033918e,...)
at witness_display_spinlock+0x75
witness_checkorder(c264bce8,9,c033918e,82a,0,...) at witness_checkorder+0x839
__lockmgr_args(c264bce8,80100,c264bd04,0,0,...) at __lockmgr_args+0x7f5
vop_stdlock(d58f6988,c01089fb,c032177a,80100,c264bc90,...) at vop_stdlock+0x62
VOP_LOCK1_APV(c0364b00,d58f6988,c24e2824,c0395920,c264bc90,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c264bc90,80100,c033918e,82a,8,...) at _vn_lock+0x5e
vget(c264bc90,80100,c24e2780,15e,c032169c,...) at vget+0xb9
devfs_allocv(c262d280,c24c6508,d58f6a20,9d,c0508b7c,...) at devfs_allocv+0x102
devfs_rules_apply(c24c6508,80000,d58f6c40,430,0,...) at devfs_rules_apply+0x14a
vfs_donmount(c24e2780,0,c262d380,c262d380,bf7fdde9,...) at vfs_donmount+0x14c2
nmount(c24e2780,d58f6d08,0,c,c265e2a8,...) at nmount+0x75
syscall(d58f6d48) at syscall+0x220
Xint0x80_syscall() at Xint0x80_syscall+0x22
--- syscall (378, FreeBSD ELF32, nmount), eip = 0x280e724b, esp =
0xbf7fddbc, ebp = 0xbf7fe318 ---

If I then try to umount the defvs, even if the unmount fails because
the path is busy, I get a similar one:

lock order reversal:
 1st 0xc2673488 nfs (nfs) @ /usr/src/sys/kern/vfs_mount.c:1204
 2nd 0xc2673270 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2203
KDB: stack backtrace:
X_db_sym_numargs(c032f02b,d596ba48,c0108c55,c00f906b,c0331eb2,...) at
X_db_sym_numargs+0x146
kdb_backtrace(c00f906b,c0331eb2,c22be388,c22bdea8,d596baa4,...) at
kdb_backtrace+0x29
witness_display_spinlock(c0331eb2,c2673270,c033930d,c22bdea8,c033918e,...)
at witness_display_spinlock+0x75
witness_checkorder(c2673270,9,c033918e,89b,0,...) at witness_checkorder+0x839
__lockmgr_args(c2673270,80100,c267328c,0,0,...) at __lockmgr_args+0x7f5
vop_stdlock(d596bbc0,0,c033918e,80100,c2673218,...) at vop_stdlock+0x62
VOP_LOCK1_APV(c0378cc0,d596bbc0,c00b6e03,c0395920,c2673218,...) at
VOP_LOCK1_APV+0xb5
_vn_lock(c2673218,80100,c033918e,89b,0,...) at _vn_lock+0x5e
insmntque(d596bc64,c014e0ce,c2673218,0,c03389a0,...) at insmntque+0x288
vrele(c2673218,0,c03389a0,4f9,c036dfa0,...) at vrele+0x10
dounmount(c2677508,8000000,c2777a00,47e,2,...) at dounmount+0x3ce
unmount(c2777a00,d596bd08,0,c,c27757f8,...) at unmount+0x2ff
syscall(d596bd48) at syscall+0x220
Xint0x80_syscall() at Xint0x80_syscall+0x22
--- syscall (22, FreeBSD ELF32, unmount), eip = 0x280d870f, esp =
0xbf7fe58c, ebp = 0xbf7fe658 ---

Both seem to occur only once per boot.  I've tried both multiply
mounting/unmounting the same filesystem and mounting/unmounting
multiple devfs mounts on various different NFS mounts, but I've never
gotten more than one report for nmount and one for unmount.

It doesn't seem to hurt anything; should I bug report it?  If so, is
there anything I can do to help with it, as far as further diagnostics
or fixing it?

Thanks!


More information about the freebsd-hackers mailing list