Re: How to handle non-local renames?

[Al Viro <viro@ftp.linux.org.uk>]

On Fri, Sep 22, 2006 at 08:22:19AM +0200, Miklos Szeredi wrote:
> > 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.

Simpler: if alias and our dentry share the parent, it's locked and
we can rename without s_vfs_rename_mutex.  If they do not, walk the
tree under alias, unhash all non-directories and kill all directories.

We keep local renames, we keep renames within directory and cross-directory
rename on server ends up with invalidation when client notices it.

We don't _care_ if lookup() is not from rename.  That's OK.