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 03:43:12 +0100
From:   Al Viro <viro@zeniv.linux.org.uk>
To:     NeilBrown <neilb@suse.de>
Cc:     Jeff Layton <jlayton@kernel.org>,
        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>,
        Christoph Hellwig <hch@lst.de>
Subject: Re: allowing for a completely cached umount(2) pathwalk
Message-ID: <20230414024312.GF3390869@ZenIV>
References: <95ee689c76bf034fa2fe9fade0bccdb311f3a04f.camel@kernel.org>
 <168142566371.24821.15867603327393356000@noble.neil.brown.name>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <168142566371.24821.15867603327393356000@noble.neil.brown.name>
Sender: Al Viro <viro@ftp.linux.org.uk>
Precedence: bulk

On Fri, Apr 14, 2023 at 08:41:03AM +1000, NeilBrown wrote:

> The path name that appears in /proc/mounts is the key that must be used
> to find and unmount a filesystem.  When you do that "find"ing you are
> not looking up a name in a filesystem, you are looking up a key in the
> mount table.

No.  The path name in /proc/mounts is *NOT* a key - it's a best-effort
attempt to describe the mountpoint.  Pathname resolution does not work
in terms of "the longest prefix is found and we handle the rest within
that filesystem".

> We could, instead, create an api that is given a mount-id (first number
> in /proc/self/mountinfo) and unmounts that.  Then /sbin/umount could
> read /proc/self/mountinfo, find the mount-id, and unmount it - all
> without ever doing path name lookup in the traditional sense.
> 
> But I prefer your suggestion.  LOOKUP_MOUNTPOINT could be renamed
> LOOKUP_CACHED, and it only finds paths that are in the dcache, never
> revalidates, at most performs simple permission checks based on cached
> content.

umount /proc/self/fd/42/barf/something

Discuss.

OTON, umount-by-mount-id is an interesting idea, but we'll need to decide
what would the right permissions be for it.

But please, lose the "mount table is a mapping from path prefix to filesystem"
notion - it really, really is not.  IIRC, there are systems that work that way,
but it's nowhere near the semantics used by any Unices, all variants of Linux
included.