Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 4 May 2023 13:19:06 +0200
From:   Christian Brauner <brauner@kernel.org>
To:     Jan Kara <jack@suse.cz>
Cc:     Miklos Szeredi <miklos@szeredi.hu>,
        Jeff Layton <jlayton@kernel.org>,
        Chuck Lever <chuck.lever@oracle.com>,
        linux-fsdevel@vger.kernel.org, linux-unionfs@vger.kernel.org,
        linux-nfs@vger.kernel.org, linux-api@vger.kernel.org,
        Amir Goldstein <amir73il@gmail.com>,
        Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [PATCH v2 3/4] exportfs: allow exporting non-decodeable file
 handles to userspace
Message-ID: <20230504-unruhen-lauftraining-d676c7702fea@brauner>
References: <20230502124817.3070545-1-amir73il@gmail.com>
 <20230502124817.3070545-4-amir73il@gmail.com>
 <20230503172314.kptbcaluwd6xiamz@quack3>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20230503172314.kptbcaluwd6xiamz@quack3>
Precedence: bulk

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@kernel.org>