lock order reversal bufwait/dirhash
rpaulo at FreeBSD.org
Wed Jun 9 13:05:14 UTC 2010
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) @ /data/builder/c13-2010-06-07/head/sys/kern/vfs_bio.c:2575
>> 2nd 0xc343f000 dirhash (dirhash) @ /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?
More information about the freebsd-current