Re: lock order reversal bufwait/dirhash

On 9 Jun 2010, at 12:58, John Baldwin wrote:

> On Wednesday 09 June 2010 3:51:52 am Bernd Walter wrote:
>> Got this during installworld (source on NFS, destination UFS on CF-card)
>> Source is current checked out yesterday.
>> 
>> lock order reversal:
>> 1st 0xc28b85b4 bufwait (bufwait) _at_ /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575
>> 2nd 0xc343f000 dirhash (dirhash) _at_ /data/builder/c13-2010-06-07/head/sys/ufs/ufs/ufs_dirhash.c:283
>> KDB: stack backtrace:
> 
> Known false positive.  From ufs_dirhash.c:
> 
> /*
> * Locking:
> *
> * The relationship between inode and dirhash is protected either by an
> * exclusive vnode lock or the vnode interlock where a shared vnode lock
> * may be used.  The dirhash_mtx is acquired after the dirhash lock.  To
> * handle teardown races, code wishing to lock the dirhash for an inode
> * when using a shared vnode lock must obtain a private reference on the
> * dirhash while holding the vnode interlock.  They can drop it once they
> * have obtained the dirhash lock and verified that the dirhash wasn't
> * recycled while they waited for the dirhash lock.
> *
> * ufsdirhash_build() acquires a shared lock on the dirhash when it is
> * successful.  This lock is released after a call to ufsdirhash_lookup().
> *
> * Functions requiring exclusive access use ufsdirhash_acquire() which may
> * free a dirhash structure that was recycled by ufsdirhash_recycle().
> *
> * The dirhash lock may be held across io operations.
> *
> * WITNESS reports a lock order reversal between the "bufwait" lock
> * and the "dirhash" lock.  However, this specific reversal will not
> * cause a deadlock.  To get a deadlock, one would have to lock a
> * buffer followed by the dirhash while a second thread locked a
> * buffer while holding the dirhash lock.  The second order can happen
> * under a shared or exclusive vnode lock for the associated directory
> * in lookup().  The first order, however, can only happen under an
> * exclusive vnode lock (e.g. unlink(), rename(), etc.).  Thus, for
> * a thread to be doing a "bufwait" -> "dirhash" order, it has to hold
> * an exclusive vnode lock.  That exclusive vnode lock will prevent
> * any other threads from doing a "dirhash" -> "bufwait" order.
> */

Can we tell witness not to complain then?

Regards,
--
Rui Paulo