Re: [PATCH RFC] fuse: check if system-wide io_uring is enabled

[Jens Axboe <axboe@kernel.dk>]

> On 10/21/25 23:56, Jens Axboe wrote:
>> On 10/21/25 2:31 PM, Bernd Schubert wrote:
>>> Add check_system_io_uring() to determine if systee-wide io_uring is
>>> available for a FUSE mount. This is useful because FUSE io_uring
>>> can only be enabled if the system allows it. Main issue with
>>> fuse-io-uring is that the mount point hangs until queues are
>>> initialized. If system wide io-uring is disabled queues cannot
>>> be initialized and the mount will hang till forcefully umounted.
>>> Libfuse solves that by setting up the ring before replying
>>> to FUSE_INIT, but we also have to consider other implementations
>>> and might get easily missed in development.
>>>
>>> When mount specifies user_id and group_id (e.g., via unprivileged
>>> fusermount with s-bit) not equal 0, the permission check must use
>>> the daemon's credentials, not the mount task's (root) credentials.
>>> Otherwise io_uring_allowed() incorrectly allows io_uring due to
>>> root's CAP_SYS_ADMIN capability.
>>
>> Rather than need various heuristics, it'd be a lot better if asking for
>> fuse-io_uring would just not "hang" at mount time and be able to recover
>> better?
> 
> We can consider this as well. Issue is that fuse has a limit on
> background requests that is protected with a lock. And there is lock order
> to handle. Initially I didn't have this hanging mount, until I handled
> this background request limit in fuse-io-uring with the lock order. 
> I.e. when one switches from /dev/fuse read/write to io-uring lock order
> changes.
> A way to avoid that issue is to split the background request limit equally
> between queues. Although I wouldn't like to do that before fallback
> to other queues is possible - which brings its own discussion points
> 
> https://lore.kernel.org/r/20251003-reduced-nr-ring-queues_3-v2-0-742ff1a8fc58@ddn.com

In any case, I do think it's just wrong to both need to add heuristics,
and then still not be able to catch all of the cases where limitations
prevent you from initializing without hanging. That does seem like the
crux of the issue to me, and this more of a work-around than anything
else.

>> There are also other considerations that may mean that part of init will
>> fail, doesn't seem like the best idea to me to attempt to catch all of
>> this rather than just be able to gracefully handle errors at
>> initialization time.
> 
> It is still doesn't seem to be right to me that fuse advertizes io-uring
> in FUSE_INIT to the daemon, when system wide io-uring is disabled.

On the surface, I agree. But I don't think you can catch all the cases
anyway, or if you could, it'd be fragile and may change. And then it's
just a bit of false pretense. I'd just view it as a "the kernel supports
the feature", which is true.

-- 
Jens Axboe