On Wed, May 03, 2023 at 07:23:14PM +0200, Jan Kara wrote: > On Tue 02-05-23 15:48:16, Amir Goldstein wrote: > > 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. > > Christian (or Al), are you OK with sparing one AT_ flag for this > functionality? Otherwise the patch series looks fine to me so I'd like to > queue it into my tree. Thanks! At first it looked like there are reasons to complain about this on the grounds that this seems like a flag only for a single system call. But another look at include/uapi/linux/fcntl.h reveals that oh well, the AT_* flag namespace already contains system call specific flags. The overloading of AT_EACCESS and AT_REMOVEDIR as 0x200 is especially creative since it doesn't even use an infix like the statx specific flags. Long story short, since there's already overloading of the flag namespace happening it wouldn't be unprecedent or in any way wrong if this patch just reused the 0x200 value as well. In fact, it might come in handy since it would mean that we have the bit you're using right now free for a flag that is meaningful for multiple system calls. So something to consider but you can just change that in-tree as far as I'm concerned. All this amounts to a long-winded, Acked-by: Christian Brauner <brauner@xxxxxxxxxx>
