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:     "Jeff Layton" <jlayton@kernel.org>
Cc:     "Christian Brauner" <brauner@kernel.org>,
        "Al Viro" <viro@zeniv.linux.org.uk>,
        "Dave Wysochanski" <dwysocha@redhat.com>,
        "linux-fsdevel" <linux-fsdevel@vger.kernel.org>,
        "linux-nfs" <linux-nfs@vger.kernel.org>,
        "David Howells" <dhowells@redhat.com>,
        "Christoph Hellwig" <hch@lst.de>
Subject: Re: [PATCH/RFC] VFS: LOOKUP_MOUNTPOINT should used cached info
 whenever possible.
In-reply-to: <85774a5de74b2b7828c8b8f7e041f0e9e2bc6094.camel@kernel.org>
References: <95ee689c76bf034fa2fe9fade0bccdb311f3a04f.camel@kernel.org>,
 <168168683217.24821.6260957092725278201@noble.neil.brown.name>,
 <20230417-beisein-investieren-360fa20fb68a@brauner>,
 <6c08ad94ca949d0f3525f7e1fc24a72c50affd59.camel@kernel.org>,
 <20230417-relaxen-selektiert-4b4b4143d7f6@brauner>,
 <85774a5de74b2b7828c8b8f7e041f0e9e2bc6094.camel@kernel.org>
Date:   Tue, 18 Apr 2023 07:34:14 +1000
Message-id: <168176725469.24821.12655103124286729608@noble.neil.brown.name>
Precedence: bulk

On Tue, 18 Apr 2023, Jeff Layton wrote:
> 
> The last thing we want in that case is for the server to decide to
> change some intermediate dentry in between the two operations. Best
> case, you'll get back ENOENT or something when the pathwalk fails. Worst
> case, the server swaps what are two different mountpoints on your client
> and you unmount the wrong one.

Actually, the last think I want is for the server to do something that
causes a directory to be invalidated (d_invalidate()).  Then any mount
points below there get DETACHed and we lose any change to use MNT_FORCE
or to wait for the unmount to complete.  Of course this can also happen
during any other access, not just umount....

> 
> If we don't revaliate, then we're no worse off, and may be better off if
> something hinky happens to the server of an intermediate dentry in the
> path.

Exactly.  If we don't revalidate we might use old data, but it will be
old data that were were allowed to access.  It might be data that we are
not now allowed to access, but it will never be new data that were have
never been allowed to access.

Thanks,
NeilBrown