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

["Thomas Bertschinger" <tahbertschinger@gmail.com>]

On Tue Aug 19, 2025 at 9:11 AM MDT, Jens Axboe wrote:
> I'll take a look at this, but wanted to mention that I dabbled in this
> too a while ago, here's what I had:
>
> https://git.kernel.dk/cgit/linux/log/?h=io_uring-handle

Thanks! That is helpful. Right away I see something you included that I
missed: requiring CONFIG_FHANDLE. Missing that would explain the build
failure emails I got on this series.

I'll include that in v2, when I get around to that--hopefully soon.

>
> Probably pretty incomplete, but I did try and handle some of the
> cases that won't block to avoid spurious -EAGAIN and io-wq usage.

So for the non-blocking case, what I am concerned about is code paths
like this:

do_handle_to_path()
  -> exportfs_decode_fh_raw()
    -> fh_to_dentry()
      -> xfs_fs_fh_to_dentry()
        ... -> xfs_iget()
      OR
      -> ext4_fh_to_dentry()
        ... -> ext4_iget()

Where there doesn't seem to be any existing way to tell the FS
implementation to give up and return -EAGAIN when appropriate. I wasn't
sure how to do that without modifying the signature of fh_to_dentry()
(and fh_to_parent()) which seems awfully invasive for this.

(Using a flag in task_struct to signify "don't block" was previously
discussed:
https://lore.kernel.org/io-uring/22630618-40fc-5668-078d-6cefcb2e4962@kernel.dk/
and that could allow not needing to pass a flag via function argument,
but I agree with the conclusion in that email chain that it's an ugly
solution.)

Any thoughts on that? This seemed to me like there wasn't an obvious
easy solution, hence why I just didn't attempt it at all in v1.
Maybe I'm missing something, though.

Aside from fh_to_dentry(), there is I/O that may arise from
reconnecting the dentry, as Amir pointed out earlier (like in
reconnect_one()). Handling that would, I think, be simpler because it
would only require modifying the generic code under reconnect_path() and
not each filesystem implementation.