[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <173498644096.11072.12807652552648634855@noble.neil.brown.name>
Date: Tue, 24 Dec 2024 07:40:40 +1100
From: "NeilBrown" <neilb@...e.de>
To: "Al Viro" <viro@...iv.linux.org.uk>
Cc: "Christian Brauner" <brauner@...nel.org>, "Jan Kara" <jack@...e.cz>,
"Linus Torvalds" <torvalds@...ux-foundation.org>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 10/11] VFS: take a shared lock for create/remove directory
operations.
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
Powered by blists - more mailing lists