Old LOR between devfs & devfsmount resurfacing?

[Attilio Rao]

2008/2/7, Kostik Belousov <kostikbel at gmail.com>:
> On Wed, Feb 06, 2008 at 11:11:06AM -0800, Marcel Moolenaar wrote:
>  > All,
>  >
>  > I just ran into the following LOR after upgrading my PowerPC box:
>  >
>  > lock order reversal:
>  >  1st 0xdbee94 devfs (devfs) @ /nfs/freebsd/8.x/src/sys/kern/
>  > vfs_subr.c:2061
>  >  2nd 0xdfb014 devfsmount (devfsmount) @ /nfs/freebsd/8.x/src/sys/fs/
>  > devfs/devfs_vnops.c:201
>  > KDB: stack backtrace:
>  > 0xdc0febc8: at kdb_backtrace+0x4c
>  > 0xdc0febd8: at witness_checkorder+0x704
>  > 0xdc0fec28: at _sx_xlock+0x8c
>  > 0xdc0fec48: at devfs_allocv+0x138
>  > 0xdc0fec88: at devfs_root+0x5c
>  > 0xdc0fecb8: at set_rootvnode+0x44
>  > 0xdc0fece8: at vfs_mountroot+0x344
>  > 0xdc0fed48: at start_init+0x88
>  > 0xdc0feda8: at fork_exit+0xb4
>  > 0xdc0fedc8: at fork_trampoline+0xc
>  > KDB: enter: witness_checkorder
>  > [thread pid 1 tid 100001 ]
>  > Stopped at      0x28ee68:       addi    r0, r0, 0x0
>  >
>  > It seems that this is a LOR reported in 2006 and fixed
>  > in 2006 as well. Do other people see this too, or should
>  > I suspect my sources?
>
>
> I believe this is a false positive, caused by the way the witness works.
>  Attilio recently added the witness support for the lockmgr, that caused
>  this and at least two more LORs to be printed on startup.
>
>  Correct lock order is devfs vnode -> devfs mount sx lock. When
>  allocating new devfs vnode, see devfs_allocv(), the newly created
>  vnode is locked while devfs mount lock already held (see line 250 of
>  fs/devfs/devfs_vnops.c). Nonetheless, this cannot cause deadlock since
>  no other thread can find the new vnode, and thus perform the other lock
>  order for this vnode lock.
>
>  The fix is to shut the witness in this particular case. Attilio, how to
>  do this ?

Just add LK_NOWITNESS for one of the lock involved in the lockinit().

Attilio

-- 
Peace can only be achieved by understanding - A. Einstein