On Thu, May 4, 2023 at 2:19 PM Christian Brauner <brauner@xxxxxxxxxx> wrote: > > 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. > I had considered this myself as well... Couldn't decide if this was ugly or not. Obviously, I do not mind which value the flag gets. > 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> Thanks, Amir.
