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
