Re: LOR: vfs_mount.c (ufs) / msdosfs_vfsops.c (devfs)

On Sunday 07 February 2010 11:00:32 am Bruce Cran wrote:
> Running -CURRENT from today, I unmounted the msdosfs filesystem on my 
> phone and got the following LOR:
> 
> lock order reversal:
>  1st 0xffffff00c51279f8 ufs (ufs) _at_ /usr/src/sys/kern/vfs_mount.c:1204
>  2nd 0xffffff010b892278 devfs (devfs) _at_ 
> /usr/src/sys/modules/msdosfs/../../fs/msdosfs/msdosfs_vfsops.c:944
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2a
> _witness_debugger() at witness_debugger+0x2e
> witness_checkorder() at witness_checkorder+0x81e
> __lockmgr_args() at __lockmgr_args+0xd11
> vop_stdlock() at vop_stdlock+0x39
> VOP_LOCK1_APV() VOP_LOCK1_APV+0x9b
> _vn_lock() at _vn_lock+0x47
> msdosfs_sync() at msdosfs_sync+0x227
> dounmount() at dounmount+0x2ca
> unmount() at unmount+0x216
> syscall() at syscall+0x2a2
> Xfast_syscall() at Xfast_syscall+0xe1
> --- syscall (22, FreeBSD ELF64, unmount), rip = 0x8006a1e3c, rsp = 
> 0x7fffffffe3a8, rbp = 0x800c08010 ---

This is due to holding a lock on the coveredvp vnode for most of unmount(2).
Probably it should not be held for all of that.  Perhaps it is safe to just 
keep the vnode referenced instead, or could the handling for coveredvp just
move to the end of the function where it is now vput?

-- 
John Baldwin