various vfs LORs

[Kostik Belousov]

On Fri, Aug 21, 2009 at 02:05:13PM -0400, Rick Macklem wrote:
> 
> 
> 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) @ /usr/src/sys/kern/vfs_syscalls.c:4097
> >> 2nd 0xffffff80a5129968 bufwait (bufwait) @ 
> >> /usr/src/sys/kern/vfs_bio.c:1835
> >> 3rd 0xffffff00046de620 nfs (nfs) @ /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.

We could add LK_NOWITNESS to nfsclient/nfs_subr.c:161.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-current/attachments/20090821/42c89b2f/attachment.pgp