On 2024-05-26, Christoph Hellwig <hch@xxxxxxxxxxxxx> 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. The existing interface already provides a mount ID which is not even safe without rebooting. The purpose of the mount ID (in the existing API) is to allow userspace to make sure they know which filesystem mount the file handle came from so they can store the relevant information (fsid, etc) to make sure they know which superblock the mount came from when it comes to doing open_by_handle_at(2). However, there is a race between getting the mount ID from name_to_handle_at() and parsing /proc/self/mountinfo, which means that userspace cannot ever be sure that they know the correct mount the file handle came from (the man page for open_by_handle_at mentions this issue explicitly). Getting the ability to get a 64-bit mount ID would allow userspace to use statmount(2) directly, avoiding this race. You're quite right that obviously you wouldn't want to just store the mount ID. An alternative would be to return something unique to the filesystem superblock, but as far as I can tell there is no guarantee that every Linux filesystem's fsid is sufficiently unique to act as a globally unique identifier. At least with a 64-bit mount ID and statmount(2), userspace can decide what information is needed to get sufficiently unique information about the source filesystem. -- Aleksa Sarai Senior Software Engineer (Containers) SUSE Linux GmbH <https://www.cyphar.com/>
Attachment:
signature.asc
Description: PGP signature
