[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
I think I've found the reason of the deadlock between ufs_rename() and
cache_lookup() (see "tstile syndrome" thread on this list). The deadlock
would exist in both ufs_rename() and wapbl_ufs_rename() which would explain
why some people see it with or without -o log mounts.
cache_lookup() does (kern/vfs_cache.c around line 400):
error = vn_lock(vp, LK_EXCLUSIVE);
vn_lock(dvp, LK_EXCLUSIVE | LK_RETRY);
wapbl_ufs_rename() and ufs_rename() both do:
vn_lock(fvp) just after basic checks for permission, cross-device, etc
vn_lock(fdvp) in the "unlink the source" case, or if (newparent).
Which one is right ? Should the parent be locked before the entry, or
the opposite ?
Assuming the former, would unlocking fvp before locking fdvp work ?
We're about to do a relookup() so it looks like it could be safely done,
provided we check nothing bad happened while fvp was unlocked.
And now this is the question: how do we check that nothing bad happened ?
Note that as we hold a reference to the vnode, maybe there's no more
to check than the return value from vn_lock() ?
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
Main Index |
Thread Index |