lock order reversal bufwait/dirhash
jhb at freebsd.org
Wed Jun 9 12:44:42 UTC 2010
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:
* 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.
More information about the freebsd-current