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;
Date:   Sat, 27 Aug 2022 02:21:12 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     NeilBrown <neilb@suse.de>
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 09/10] VFS: add LOOKUP_SILLY_RENAME
Message-ID: <YwlxiCt3TvzdEhUl@ZenIV>
References: <166147828344.25420.13834885828450967910.stgit@noble.brown>
 <166147984377.25420.5747334898411663007.stgit@noble.brown>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <166147984377.25420.5747334898411663007.stgit@noble.brown>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Fri, Aug 26, 2022 at 12:10:43PM +1000, NeilBrown wrote:
> When performing a "silly rename" to avoid removing a file that is still
> open, we need to perform a lookup in a directory that is already locked.
> 
> In order to allow common functions to be used for this lookup, introduce
> LOOKUP_SILLY_RENAME which affirms that the directory is already locked
> and that the vfsmnt is already writable.
> 
> When LOOKUP_SILLY_RENAME is set, path->mnt can be NULL.  As
> i_op->rename() doesn't make the vfsmnt available, this is unavoidable.
> So we ensure that a NULL ->mnt isn't fatal.

This one is really disgusting.  Flag-dependent locking is a pretty much
guaranteed source of PITA and "magical" struct path is, again, asking for
trouble.

You seem to be trying for simpler call graph and you end up paying with
control flow that is much harder to reason about.