Date: Wed, 9 Jun 2010 14:05:09 +0100 From: Rui Paulo <rpaulo@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: Bernd Walter <ticso@cicely7.cicely.de>, freebsd-current@freebsd.org, ticso@cicely.de Subject: Re: lock order reversal bufwait/dirhash Message-ID: <821FE180-FBE3-4826-B773-B8074EDCC555@FreeBSD.org> In-Reply-To: <201006090758.37330.jhb@freebsd.org> References: <20100609075152.GC72453@cicely7.cicely.de> <201006090758.37330.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >>=20 >> 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: >=20 > Known false positive. =46rom ufs_dirhash.c: >=20 > /* > * 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?821FE180-FBE3-4826-B773-B8074EDCC555>