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;
MIME-Version: 1.0
References: <95ee689c76bf034fa2fe9fade0bccdb311f3a04f.camel@kernel.org> <20230414023211.GE3390869@ZenIV>
In-Reply-To: <20230414023211.GE3390869@ZenIV>
From:   David Wysochanski <dwysocha@redhat.com>
Date:   Fri, 14 Apr 2023 09:16:43 -0400
Message-ID: <CALF+zOnbBf01ThYyv2sByyjBJww6pbkza93ixb1Vdh4i3B1+BQ@mail.gmail.com>
Subject: Re: allowing for a completely cached umount(2) pathwalk
To:     Al Viro <viro@zeniv.linux.org.uk>
Cc:     Jeff Layton <jlayton@kernel.org>,
        Christian Brauner <brauner@kernel.org>,
        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>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Apr 13, 2023 at 10:34=E2=80=AFPM Al Viro <viro@zeniv.linux.org.uk> =
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?
>

Speaking in the context of the original reproducer:
This does work if you "umount -l /A" - the underlying "/A" mount,
but not if you do "umount -l /A/B" (both have lost their access on
the server).

The problem with this is IMO, it is not very intuitive to lazy unmount
the root of a whole tree like that.  Also, the customer's case was autofs,
and I don't think autofs does this, it tries to umount the children
first and gets stuck there in this scenario.

But overall yes it does make sense, IMO.

> > 2/ disallow ->lookup operations: a umount is about removing an existing
> > mount, so the dentries had better already be there.
>
> That changes the semantics; as it is, you need exec permissions on the
> entire path...
>
> > Is this a terrible idea? Are there potentially problems with
> > containerized setups if we were to do something like this? Are there
> > better ways to solve this problem (and others like it)? Maybe this woul=
d
> > be best done with a new UMOUNT_CACHED flag for umount2()?
>
> We already have lazy umount.  And what will you do to symlinks you run
> into along the way?  They *are* traversed; requiring the caller to
> canonicalize them will only shift the problem to userland...
>