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@xxxxxxxxx/ 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.
