Re: [PATCH 10/11] VFS: take a shared lock for create/remove directory operations.

[NeilBrown]

On Mon, 23 Dec 2024, Al Viro wrote:
> On Mon, Dec 23, 2024 at 06:11:16PM +1100, NeilBrown wrote:
> > ... Yes, thanks.
> > 
> > So I need __d_unalias() to effectively do a "try_lock" of
> > DCACHE_PAR_UPDATE and hold the lock across __d_move().
> > I think that would address the concerned you raised.
> > 
> > Did you see anything else that might be problematic?
> 
> That might work with ->d_parent, but it won't help with ->d_name
> in same-parent case of __d_unalias()...
> 

Why would the same-parent case be any different?
Certainly it doesn't need s_vfs_rename_mutex and it there is no second
parent to get a shared lock on.  But we would still need to set
DCACHE_PAR_UPDATE under ->d_lock on "alias".  If we found that it was
already set and instead failed with -ESTALE, that would prevent
__d_unalias from changing anything including ->d_name after
lookup_and_lock has checked that the parent and d_name are unchanged
(until done_lookup_and_lock is called of course).

What am I missing?
Thanks,
NeilBrown