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.
