Re: various vfs LORs

On Wed, 19 Aug 2009, Rick C. Petty wrote:

>
> This LOR doesn't seem to be reported anywhere:
>
>> lock order reversal:
>>  1st 0xffffff00046de7f8 nfs (nfs) _at_ /usr/src/sys/kern/vfs_syscalls.c:4097
>>  2nd 0xffffff80a5129968 bufwait (bufwait) _at_ /usr/src/sys/kern/vfs_bio.c:1835
>>  3rd 0xffffff00046de620 nfs (nfs) _at_ /usr/src/sys/nfsclient/nfs_node.c:161
>> 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+0xcf3
>> nfs_nget() at nfs_nget+0x1c9
>> nfs_readdirplusrpc() at nfs_readdirplusrpc+0x7cc
>> nfs_doio() at nfs_doio+0x617
>> nfs_bioread() at nfs_bioread+0xa9f
>> nfs_readdir() at nfs_readdir+0x85
>> kern_getdirentries() at kern_getdirentries+0x12e
>> getdirentries() at getdirentries+0x23
>> syscall() at syscall+0x1af
>> Xfast_syscall() at Xfast_syscall+0xe1
>> --- syscall (196, FreeBSD ELF64, getdirentries), rip = 0x8009d11dc, rsp = 0x7fffffffc3a8, rbp = 0x1 ---

Since the 3rd one is locking a newly allocated nfs vnode (that isn't yet 
in the mount point list, etc), I don't think this will cause a problem
and I don't see an easy way to avoid it.

rick