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

[Jeff Layton <jlayton@kernel.org>]

On Fri, 2023-04-14 at 03:43 +0100, Al Viro wrote:
> 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
> 

Does any of that involve talking to the server? I don't necessarily see
a problem with doing the above. If "something" is in cache then that
should still work.

The main idea here is that we want to avoid communicating with the
backing store during the umount(2) pathwalk.

> 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.

I'm not opposed to something by umount-by-mount-id either. All of this
seems like something that should probably rely on CAP_SYS_ADMIN.
-- 
Jeff Layton <jlayton@kernel.org>