summaryrefslogtreecommitdiffstats
path: root/fs/notify
diff options
context:
space:
mode:
authorAmir Goldstein <amir73il@gmail.com>2023-05-02 15:48:16 +0300
committerJan Kara <jack@suse.cz>2023-05-25 13:16:57 +0200
commit96b2b072ee62be8ae68c8ecf14854c4d0505a8f8 (patch)
tree2c8924c6c6b6bf90e01257d17f25bb0db6ef739a /fs/notify
parent304e9c83e80d5cbe20ab64ffa1fac9fc51d30bc9 (diff)
downloadlinux-96b2b072ee62be8ae68c8ecf14854c4d0505a8f8.tar.gz
linux-96b2b072ee62be8ae68c8ecf14854c4d0505a8f8.tar.bz2
linux-96b2b072ee62be8ae68c8ecf14854c4d0505a8f8.zip
exportfs: allow exporting non-decodeable file handles to userspace
Some userspace programs use st_ino as a unique object identifier, even though inode numbers may be recycable. This issue has been addressed for NFS export long ago using the exportfs file handle API and the unique file handle identifiers are also exported to userspace via name_to_handle_at(2). fanotify also uses file handles to identify objects in events, but only for filesystems that support NFS export. Relax the requirement for NFS export support and allow more filesystems to export a unique object identifier via name_to_handle_at(2) with the flag AT_HANDLE_FID. A file handle requested with the AT_HANDLE_FID flag, may or may not be usable as an argument to open_by_handle_at(2). To allow filesystems to opt-in to supporting AT_HANDLE_FID, a struct export_operations is required, but even an empty struct is sufficient for encoding FIDs. Acked-by: Jeff Layton <jlayton@kernel.org> Acked-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Amir Goldstein <amir73il@gmail.com> Acked-by: Christian Brauner <brauner@kernel.org> Signed-off-by: Jan Kara <jack@suse.cz> Message-Id: <20230502124817.3070545-4-amir73il@gmail.com>
Diffstat (limited to 'fs/notify')
0 files changed, 0 insertions, 0 deletions