Re: [PATCH v3 07/19] VFS: Add LOOKUP_SHARED flag.
Amir Goldstein <[email protected]>
| Newsgroups | org.kernel.vger.linux-unionfs,org.kernel.vger.linux-efi,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs |
|---|---|
| Message-ID | <CAOQ4uxi8rqkbhK4=8N1ncfU1m6bjdHLbinSf=j3k0oVEaSa-wA@mail.gmail.com> |
On Mon, Apr 27, 2026 at 6:06 AM NeilBrown <[email protected]> wrote: > > From: NeilBrown <[email protected]> > > Some ->lookup handlers will need to drop and retake the parent lock, so > they can safely use d_alloc_parallel(). > > ->lookup can be called with the parent lock either exclusive or shared. > > A new flag, LOOKUP_SHARED, tells ->lookup how the parent is locked. > > This is rather ugly, but will be gone soon after we move > d_alloc_parallel() out of the directory lock as ->lookup() will *always* > called with a shared lock on the parent. Neil, Forgive me for being skeptical about the *always* part. How long ago did we add ->iterate_shared()? It's true that Linus eventually got rid of ->iterate(), but we did not get rid of the assumption that iterate_shared() might be upgraded to exclusive lock. The obvious reason is that *someone* needs to do this work for old filesystems, which are also hard to test and nobody wants to touch them. I have nothing against this patch, but I think it is more realistic to state that LOOKUP_SHARED is here to stay, so if you think it is too ugly, maybe there is something to be done about it. Personally, I do not see the ugliness though. Am I misjudging the situation of shared lookup wrt old filesystems? Thanks, Amir.