From: Christian Brauner Date: Mon, 2 Sep 2024 14:15:44 +0000 (+0200) Subject: Merge patch series "fhandle: expose u64 mount id to name_to_handle_at(2)" X-Git-Tag: v6.12-rc1~215^2~3 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=7063c229a83667fec3938999b39dad0aea12906b;p=thirdparty%2Fkernel%2Flinux.git Merge patch series "fhandle: expose u64 mount id to name_to_handle_at(2)" Aleksa Sarai says: Now that we provide a unique 64-bit mount ID interface in statx(2), 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 or having to open a file just to do statx(2). While this is not necessary if you are using AT_EMPTY_PATH and don't care about an extra statx(2) call, users that pass full paths into name_to_handle_at(2) need to know which mount the file handle comes from (to make sure they don't try to open_by_handle_at a file handle from a different filesystem) and switching to AT_EMPTY_PATH would require allocating a file for every name_to_handle_at(2) call, turning err = name_to_handle_at(-EBADF, "/foo/bar/baz", &handle, &mntid, AT_HANDLE_MNT_ID_UNIQUE); into int fd = openat(-EBADF, "/foo/bar/baz", O_PATH | O_CLOEXEC); err1 = name_to_handle_at(fd, "", &handle, &unused_mntid, AT_EMPTY_PATH); err2 = statx(fd, "", AT_EMPTY_PATH, STATX_MNT_ID_UNIQUE, &statxbuf); mntid = statxbuf.stx_mnt_id; close(fd); Also, this series adds a patch to clarify how AT_* flag allocation should work going forwards. * patches from https://lore.kernel.org/r/20240828-exportfs-u64-mount-id-v3-0-10c2c4c16708@cyphar.com: fhandle: expose u64 mount id to name_to_handle_at(2) uapi: explain how per-syscall AT_* flags should be allocated Link: https://lore.kernel.org/r/20240828-exportfs-u64-mount-id-v3-0-10c2c4c16708@cyphar.com Signed-off-by: Christian Brauner --- 7063c229a83667fec3938999b39dad0aea12906b