Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
MIME-Version: 1.0
From:   "NeilBrown" <neilb@suse.de>
To:     "Al Viro" <viro@zeniv.linux.org.uk>
Cc:     "Linus Torvalds" <torvalds@linux-foundation.org>,
        "Daire Byrne" <daire@dneg.com>,
        "Trond Myklebust" <trond.myklebust@hammerspace.com>,
        "Chuck Lever" <chuck.lever@oracle.com>,
        "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>,
        linux-fsdevel@vger.kernel.org,
        "LKML" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 01/10] VFS: support parallel updates in the one directory.
In-reply-to: <YxOUUEXAbUdFLVKk@ZenIV>
References: <166147828344.25420.13834885828450967910.stgit@noble.brown>,
 <166147984370.25420.13019217727422217511.stgit@noble.brown>,
 <YwmS63X3Sm4bhlcT@ZenIV>,
 <166173834258.27490.151597372187103012@noble.neil.brown.name>,
 <YxKaaN9cHD5yzlTr@ZenIV>,
 <166216924401.28768.5809376269835339554@noble.neil.brown.name>,
 <YxK4CiVNaQ6egobJ@ZenIV>, <YxOUUEXAbUdFLVKk@ZenIV>
Date:   Mon, 05 Sep 2022 09:33:40 +1000
Message-id: <166233442086.1168.1631109347260612253@noble.neil.brown.name>
Precedence: bulk

On Sun, 04 Sep 2022, Al Viro wrote:
> On Sat, Sep 03, 2022 at 03:12:26AM +0100, Al Viro wrote:
> 
> > Very much so.  You are starting to invent new rules for ->lookup() that
> > just never had been there, basing on nothing better than a couple of
> > examples.  They are nowhere near everything there is.
> 
> A few examples besides NFS and autofs:

Hi Al,
 thanks for these - very helpful.  I will give them due consideration
 when I write relevant documentation to include in the next posting of
 the series.

Thanks a lot,
NeilBrown


> 
> ext4, f2fs and xfs might bloody well return NULL without hashing - happens
> on negative lookups with 'casefolding' crap.
> 
> kernfs - treatment of inactive nodes.
> 
> afs_dynroot_lookup() treatment of @cell... names.
> 
> afs_lookup() treatment of @sys... names.
> 
> There might very well be more - both merged into mainline and in
> development trees of various filesystems (including devel branches
> of in-tree ones - I'm not talking about out-of-tree projects).
> 
> Note, BTW, that with the current rules it's perfectly possible to
> have this kind of fun:
> 	a name that resolves to different files for different processes
> 	unlink(2) is allowed and results depend upon the calling process
> 
> All it takes is ->lookup() deliberately *NOT* hashing the sucker and
> ->unlink() acting according to dentry it has gotten from the caller.
> unlink(2) from different callers are serialized and none of that
> stuff is ever going to be hashed.  d_alloc_parallel() might pick an
> in-lookup dentry from another caller of e.g. stat(2), but it will
> wait for in-lookup state ending, notice that the sucker is not hashed,
> drop it and retry.  Suboptimal, but it works.
> 
> Nothing in the mainline currently does that.  Nothing that I know of,
> that is.  Sure, it could be made work with the changes you seem to
> imply (if I'm not misreading you) - all it takes is lookup
> calling d_lookup_done() on its argument before returning NULL.
> But that's subtle, non-obvious and not documented anywhere...
> 
> Another interesting question is the rules for unhashing dentries.
> What is needed for somebody to do temporary unhash, followed by
> rehashing?
>