Re: [PATCHSET RFC 0/6] add support for name_to, open_by_handle_at(2) to io_uring

[Amir Goldstein <amir73il@gmail.com>]

On Fri, Aug 15, 2025 at 1:50 AM Thomas Bertschinger
<tahbertschinger@gmail.com> wrote:
>
> This series adds support for name_to_handle_at() and open_by_handle_at()
> to io_uring. The idea is for these opcodes to be useful for userspace
> NFS servers that want to use io_uring.
>
> name_to_handle_at()
> ===================
>
> Support for name_to_handle_at() is added in patches 1 and 2.
>
> In order to do a non-blocking name_to_handle_at(), a new helper
> do_name_to_handle_at() is created that takes a lookup_flags argument.
>
> This is to support non-blocking lookup when called with
> IO_URING_F_NONBLOCK--user_path_at() will be called with LOOKUP_CACHED
> in that case.
>
> Aside from the lookup, I don't think there is anything else that
> do_name_to_handle_at() does that would be a problem in the non-blocking
> case. There is a GFP_KERNEL allocation:
>
> do_name_to_handle_at()
>   -> do_path_to_handle()
>     -> kzalloc(..., GFP_KERNEL)
>
> But I think that's OK? Let me know if there's anything else I'm
> missing...
>
> open_by_handle_at()
> ===================
>
> Patch 3 is a fixup to fhandle.c:do_handle_open() that (I believe) fixes
> a bug and can exist independently of this series, but it fits in with
> these changes so I'm including it here.
>
> Support for open_by_handle_at() is added in patches 4 - 6.
>
> A helper __do_handle_open() is created that does the file open without
> installing a file descriptor for it. This is needed because io_uring
> needs to decide between using a file descriptor or a fixed file.
>
> No attempt is made to support a non-blocking open_by_handle_at()--the
> attempt is always immediately returned with -EAGAIN if
> IO_URING_F_NONBLOCK is set.
>
> This isn't ideal and it would be nice to add support for non-blocking
> open by handle in the future. This would presumably require updates to
> the ->encode_fh() implementation for filesystems that want to
> support this.

Correction: ->encode_fh() is for name_to_handle()
You want to say that ->fh_to_dentry() need to support cached lookup,
but FWIW, the blocking code is more likely to come from the
lookup in exportfs_decode_fh_raw() => ... reconnect_one()
not from the filesystem code.

The fs would "only" need to be taught to return an alias to a
cached inode and generic code would "only" need to be taught
to give up on a disconnected dir dentry.

Doesn't sound too hard (famous last words).

Thanks,
Amir.

>
> I see that lack of support for non-blocking operation was a dealbreaker
> for adding getdents to io_uring previously:
>
> https://lore.kernel.org/io-uring/20230428050640.GA1969623@dread.disaster.area/
>
> On the other hand, AFAICT, support for openat() was originally added in
> 15b71abe7b52 (io_uring: add support for IORING_OP_OPENAT) without a non-
> blocking lookup, and the possibility of non-blocking lookup later added
> in 3a81fd02045c (io_uring: enable LOOKUP_CACHED path resolution for
> filename lookups).
>
> (To be honest I'm a little confused by the history here. The commit
> message of 15b71abe7b52 says
>
> > For the normal case of a non-blocking path lookup this will complete
> > inline. If we have to do IO to perform the open, it'll be done from
> > async context.
>
> but from the commit contents this would NOT appear to be the case:
>
> > +       if (force_nonblock) {
> > +               req->work.flags |= IO_WQ_WORK_NEEDS_FILES;
> > +               return -EAGAIN;
> > +       }
>
> until the support is really added in the later commit. Am I confused or
> is the commit message wrong?)
>
> In any event, based on my reading of the history, it would appear to be
> OK to add open_by_handle_at() initially without support for inline
> completion, and then later add that when the filesystem implementations
> can be updated to support this.
>
> Please let me know if I am wrong on my interpretation of the history or
> if anyone disagrees with the conclusion.
>
> Testing
> =======
>
> A liburing branch that includes support for the new opcodes, as well as
> a test, is available at:
>
> https://github.com/bertschingert/liburing/tree/open_by_handle_at
>
> To run the test:
>
> $ ./test/open_by_handle_at.t
>
> Thomas Bertschinger (6):
>   fhandle: create helper for name_to_handle_at(2)
>   io_uring: add support for IORING_OP_NAME_TO_HANDLE_AT
>   fhandle: do_handle_open() should get FD with user flags
>   fhandle: create __do_handle_open() helper
>   io_uring: add __io_open_prep() helper
>   io_uring: add support for IORING_OP_OPEN_BY_HANDLE_AT
>
>  fs/fhandle.c                  |  85 ++++++++++++---------
>  fs/internal.h                 |   9 +++
>  include/uapi/linux/io_uring.h |   2 +
>  io_uring/opdef.c              |  14 ++++
>  io_uring/openclose.c          | 137 +++++++++++++++++++++++++++++++---
>  io_uring/openclose.h          |   5 ++
>  6 files changed, 209 insertions(+), 43 deletions(-)
>
> --
> 2.50.1
>
>