linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Amir Goldstein <amir73il@gmail.com>
To: Jeff Layton <jlayton@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>,
	Aleksa Sarai <cyphar@cyphar.com>,
	Chuck Lever <chuck.lever@oracle.com>,
	linux-fsdevel@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: [RFC PATCH 0/2] API for exporting connectable file handles to userspace
Date: Thu, 19 Sep 2024 16:06:09 +0200	[thread overview]
Message-ID: <20240919140611.1771651-1-amir73il@gmail.com> (raw)

Jeff,

These patches bring the NFS connectable file handles feature to
userspace servers.

They rely on Christian's and Aleksa's changes recently merged to v6.12.

It may not be the best timing for posting RFC patches in the middle of
the merge window and during LPC, but at least this gives you a chance to
gossip about how bad an idea this is with folks ;)

I am aware of the usability implications with connectable file handles,
which are not consistent throughout the inode lifetime (i.e. when moved
to another parent), but the nfsd feature does exists and some users (me)
are interested in exporting this feature to userspace.

The API I chose for encoding conenctable file handles is pretty
conventional (AT_HANDLE_CONNECTABLE).

The API I chose for decoding a connected fd is a bit whacky, but if
you let it sink, it could make sense - my use case is to examine an
object's current path given a previously connectable encoded file handle.

By requesting to open an O_PATH fd, relative to an O_PATH mount_fd,
I would like to get an error (ESTALE) if the path connecting mount_fd
to the would-be-opened fd is unknown.

Thought and flames are welcome.

Thanks,
Amir.


Amir Goldstein (2):
  fs: name_to_handle_at() support for connectable file handles
  fs: open_by_handle_at() support for decoding connectable file handles

 fs/fhandle.c               | 85 +++++++++++++++++++++++++-------------
 include/uapi/linux/fcntl.h |  1 +
 2 files changed, 58 insertions(+), 28 deletions(-)

-- 
2.34.1


             reply	other threads:[~2024-09-19 14:06 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-09-19 14:06 Amir Goldstein [this message]
2024-09-19 14:06 ` [RFC PATCH 1/2] fs: name_to_handle_at() support for connectable file handles Amir Goldstein
2024-09-20  7:13   ` Jeff Layton
2024-09-20  7:36     ` Jeff Layton
2024-09-20  8:40       ` Amir Goldstein
2024-09-19 14:06 ` [RFC PATCH 2/2] fs: open_by_handle_at() support for decoding " Amir Goldstein
2024-09-20 16:02   ` Jeff Layton
2024-09-20 16:38     ` Amir Goldstein
2024-09-21  5:33       ` Jeff Layton
2024-09-21  9:13         ` Aleksa Sarai
2024-09-21 10:25         ` Amir Goldstein
2024-09-21  9:15       ` Aleksa Sarai

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=20240919140611.1771651-1-amir73il@gmail.com \
    --to=amir73il@gmail.com \
    --cc=brauner@kernel.org \
    --cc=chuck.lever@oracle.com \
    --cc=cyphar@cyphar.com \
    --cc=jlayton@kernel.org \
    --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).