Lock Order Reversal in nmount/unmount of devfs on NFS

[Kostik Belousov]

On Fri, Oct 22, 2010 at 01:46:54PM -0400, Linda Messerschmidt wrote:
> 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?
The LORs are believed to be harmless.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20101022/5d890dc5/attachment.pgp