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:   Fri, 14 Apr 2023 15:57:59 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     Jeff Layton <jlayton@kernel.org>
Cc:     Christian Brauner <brauner@kernel.org>,
        Dave Wysochanski <dwysocha@redhat.com>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>,
        linux-nfs <linux-nfs@vger.kernel.org>,
        David Howells <dhowells@redhat.com>, NeilBrown <neilb@suse.de>,
        Christoph Hellwig <hch@lst.de>
Subject: Re: allowing for a completely cached umount(2) pathwalk
Message-ID: <20230414145759.GJ3390869@ZenIV>
References: <95ee689c76bf034fa2fe9fade0bccdb311f3a04f.camel@kernel.org>
 <20230414023211.GE3390869@ZenIV>
 <8d2c619d2a91f3ac925fbc8e4fc467c6b137ab14.camel@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8d2c619d2a91f3ac925fbc8e4fc467c6b137ab14.camel@kernel.org>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Fri, Apr 14, 2023 at 06:01:59AM -0400, Jeff Layton wrote:
> On Fri, 2023-04-14 at 03:32 +0100, Al Viro wrote:
> > On Thu, Apr 13, 2023 at 06:00:42PM -0400, Jeff Layton wrote:
> > 
> > > It describes a situation where there are nested NFS mounts on a client,
> > > and one of the intermediate mounts ends up being unexported from the
> > > server. In a situation like this, we end up being unable to pathwalk
> > > down to the child mount of these unreachable dentries and can't unmount
> > > anything, even as root.
> > 
> > So umount -l the stuck sucker.  What's the problem with that?
> > 
> 
> You mean lazy umount the parent that is stuck? What happens to the child
> mount in that case? Is it also eventually cleaned up?

Yes.  Lazy umount takes out the contributions to refcount due to being
present in mount tree; as soon as other references go away (opened
files, current directories, in-progress syscalls on files in there) struct
mount instance releases the active reference to filesystem instance
(struct super_block) and goes away.  Once all active references to
filesystem instance are gone, it gets shut down.

> Yeah, I hadn't considered symlinks here. Still, if we have a cached
> symlink dentry, wouldn't we also already have the symlink target in
> cache too? Or is that not guaranteed?

Not at all.  What's more, why would we have that symlink dentry cached
in the first place?  If you suddenly impose that kind of restrictions
on umount(2), you are pretty much guaranteed to break userland...

Symlink dentries are rarely pinned, BTW - they may very well be
cached if we hit them often enough, but outside of the things
like lchown()/lstat() or pathname resolution in progress that is
currently traversing that symlink... refcount is going to be zero.