From: Jeff Layton <jlayton@kernel.org>
To: Amir Goldstein <amir73il@gmail.com>,
Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>, Aleksa Sarai <cyphar@cyphar.com>,
Chuck Lever <chuck.lever@oracle.com>,
linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v4 0/3] API for exporting connectable file handles to userspace
Date: Fri, 11 Oct 2024 10:04:50 -0400 [thread overview]
Message-ID: <7355c2b54e36533cffa7716e4b95b253169ab928.camel@kernel.org> (raw)
In-Reply-To: <20241011090023.655623-1-amir73il@gmail.com>
On Fri, 2024-10-11 at 11:00 +0200, Amir Goldstein wrote:
> Christian,
>
> These patches bring the NFS connectable file handles feature to
> userspace servers.
>
> They rely on your and Aleksa's changes recently merged to v6.12.
>
> This v4 incorporates the review comments on Jeff and Jan (thanks!)
> and there does not seem to be any objection for this new API, so
> I think it is ready for staging.
>
> The API I chose for encoding conenctable file handles is pretty
> conventional (AT_HANDLE_CONNECTABLE).
>
> open_by_handle_at(2) does not have AT_ flags argument, but also, I find
> it more useful API that encoding a connectable file handle can mandate
> the resolving of a connected fd, without having to opt-in for a
> connected fd independently.
>
> I chose to implemnent this by using upper bits in the handle type field
> It may be that out-of-tree filesystems return a handle type with upper
> bits set, but AFAIK, no in-tree filesystem does that.
> I added some warnings just in case we encouter that.
>
> I have written an fstest [4] and a man page draft [5] for the feature.
>
> Thanks,
> Amir.
>
> Changes since v3 [3]:
> - Relax WARN_ON in decode and replace with pr_warn in encode (Jeff)
> - Loose the macro FILEID_USER_TYPE_IS_VALID() (Jan)
> - Add explicit check for negative type values (Jan)
> - Added fstest and man-page draft
>
> Changes since v2 [2]:
> - Use bit arithmetics instead of bitfileds (Jeff)
> - Add assertions about use of high type bits
>
> Changes since v1 [1]:
> - Assert on encode for disconnected path (Jeff)
> - Don't allow AT_HANDLE_CONNECTABLE with AT_EMPTY_PATH
> - Drop the O_PATH mount_fd API hack (Jeff)
> - Encode an explicit "connectable" flag in handle type
>
> [1] https://lore.kernel.org/linux-fsdevel/20240919140611.1771651-1-amir73il@gmail.com/
> [2] https://lore.kernel.org/linux-fsdevel/20240923082829.1910210-1-amir73il@gmail.com/
> [3] https://lore.kernel.org/linux-fsdevel/20241008152118.453724-1-amir73il@gmail.com/
> [4] https://github.com/amir73il/xfstests/commits/connectable-fh/
> [5] https://github.com/amir73il/man-pages/commits/connectable-fh/
>
> Amir Goldstein (3):
> fs: prepare for "explicit connectable" file handles
> fs: name_to_handle_at() support for "explicit connectable" file
> handles
> fs: open_by_handle_at() support for decoding "explicit connectable"
> file handles
>
> fs/exportfs/expfs.c | 17 ++++++++-
> fs/fhandle.c | 75 +++++++++++++++++++++++++++++++++++---
> include/linux/exportfs.h | 13 +++++++
> include/uapi/linux/fcntl.h | 1 +
> 4 files changed, 98 insertions(+), 8 deletions(-)
>
Aside from the relatively small stuff I noted in patch #2, this looks
fine to me.
Reviewed-by: Jeff Layton <jlayton@kernel.org>
next prev parent reply other threads:[~2024-10-11 14:04 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-10-11 9:00 [PATCH v4 0/3] API for exporting connectable file handles to userspace Amir Goldstein
2024-10-11 9:00 ` [PATCH v4 1/3] fs: prepare for "explicit connectable" file handles Amir Goldstein
2024-10-14 13:30 ` Jan Kara
2024-10-11 9:00 ` [PATCH v4 2/3] fs: name_to_handle_at() support " Amir Goldstein
2024-10-11 14:00 ` Jeff Layton
2024-10-11 14:14 ` Amir Goldstein
2024-10-11 14:18 ` Jeff Layton
2024-10-11 18:12 ` Amir Goldstein
2024-10-11 9:00 ` [PATCH v4 3/3] fs: open_by_handle_at() support for decoding " Amir Goldstein
2024-10-14 15:26 ` Jeff Layton
2024-10-11 14:04 ` Jeff Layton [this message]
2024-10-11 14:24 ` [PATCH v4 0/3] API for exporting connectable file handles to userspace Chuck Lever III
2024-10-11 18:22 ` Amir Goldstein
2024-10-11 18:40 ` Chuck Lever III
2024-10-14 8:55 ` Amir Goldstein
2024-10-14 14:52 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7355c2b54e36533cffa7716e4b95b253169ab928.camel@kernel.org \
--to=jlayton@kernel.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=chuck.lever@oracle.com \
--cc=cyphar@cyphar.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).