> I'm thinking something along the lines of the following patch on top of
> David's d_materialise_dentry(), which is already in the 2.6.18-mm
> kernels. Still untested (I'm working on that), but it attempts to do
> what you were proposing:
>
> 1) If instantiating a directory, check for aliases
> 2) If an alias is found in the dcache, attempt to rename the
> existing dentry instead of instantiating the alias.
> 3) Return ELOOP if the alias turns out to be a parent.
What I'm still worried about is that by moving the alias across
directories without holding the rename mutex, you are violating a
premise in the cross directory rename locking rules:
(2) if cross-directory rename holds the lock on filesystem, order will not
change until rename acquires all locks. (Proof: other cross-directory
renames will be blocked on filesystem lock and we don't start changing
the order until we had acquired all locks).
Possible solution:
- if lookup is being called for last components in rename then
s_vfs_rename_mutex is already held, we are OK. But currently we
don't know if lookup is called from rename.
- otherwise trylock on s_vfs_rename_mutex, if succeeds then OK.
- if fails, then alias can't be moved, make the inode bad (which
also unhashes it) and get a new inode, which will now be
unaliased.
Also need to trylock i_mutex on alias->d_parent->i_inode after having
acquired s_vfs_rename_mutex for similar reasons.
However it's getting rather ugly, and I'd rather have something
simpler.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
