Re: allowing for a completely cached umount(2) pathwalk

[Al Viro <viro@zeniv.linux.org.uk>]

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.