ufs_rename() deadlock

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

Hello,
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
--