Re: [PATCH v2 3/4] exportfs: allow exporting non-decodeable file handles to userspace

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux