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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.