On Sun, 2024-05-26 at 02:25 -0700, Christoph Hellwig wrote: > On Thu, May 23, 2024 at 01:57:32PM -0700, Aleksa Sarai wrote: > > Now that we provide a unique 64-bit mount ID interface in statx, we > > can > > now provide a race-free way for name_to_handle_at(2) to provide a > > file > > handle and corresponding mount without needing to worry about > > racing > > with /proc/mountinfo parsing. > > file handles are not tied to mounts, they are tied to super_blocks, > and they can survive reboots or (less relevant) remounts. This thus > seems like a very confusing if not wrong interfaces. I assume the reason is to give the caller a race free way to figure out which submount the path resolves to. The problem is that nothing stops another process from calling umount() before you're done parsing /proc/mountinfo and have resolved the mount id. If we're looking to change the API, then perhaps returning a file descriptor might be a better alternative? Most userland NFS servers are in any case going to follow up obtaining the filehandle with a stat() or even a full blown open() in order to get file attributes, set up file state, etc. By returning an open file descriptor to the resolved file (even if it is only an O_PATH descriptor) we could accelerate those operations in addition to solving the umount() race. Alternatively, just remove the path argument altogether, and require the descriptor argument to be an O_PATH or regular open file descriptor that resolves to the file we want to get a filehandle for. However this would require a userland NFS server to generally do a open_by_handle_at() to resolve the parent directory handle, then do an openat(O_PATH) to get the file to look up, before being able to call the name_to_handle_at() replacement. i.e. there would be 1 extra syscall. -- Trond Myklebust Linux NFS client maintainer, Hammerspace trond.myklebust@xxxxxxxxxxxxxxx
