Re: [PATCH v2] fuse: fix io-uring background queue dispatch on request completion

[Bernd Schubert <bernd@bsbernd.com>]

On 4/16/26 16:43, Miklos Szeredi wrote:
> On Wed, 8 Apr 2026 at 19:28, Joanne Koong <joannelkoong@gmail.com> wrote:
>>
>> When a background request completes via the io_uring path, the
>> background queue gets flushed to dispatch pending background requests,
>> but this is done before the connection-level background counters
>> (fc->num_background, fc->active_background) are properly accounted,
>> which may reduce effective queue depth to one.
>>
>> The connection-level counters are decremented in fuse_request_end(), but
>> flush_bg_queue() flushes the /dev/fuse path queue (fc->bg_queue), not
>> the io_uring per-queue bg one, which means pending uring background
>> requests on the queue are never dispatched in this path.
>>
>> Fix this by accounting the connection-level background counters first
>> before flushing the queue's background queue. Since
>> fuse_request_bg_finish() clears FR_BACKGROUND, fuse_request_end() will
>> skip the background cleanup branch entirely, which avoids any
>> double-decrements; it will call the wake_up(&req->waitq) branch but this
>> is effectively a no-op as background requests have no waiters on
>> req->waitq.
> 
> Does this guarantee progress if there are still requests on
> fc->bg_queue at the point when ring becomes ready?

Request allocation is still blocked until the ring is set to ready -
there should be no background requests at all.
There were a couple of issues with dynamic switching from /dev/fuse to
fuse-io-uring, a really hard one was a lock order change. I think once
we have reduced queues merged, I'm to create an additional patch set
which allow allow distribution of requests between queues. The initial
series had that, but Joanne had concerns. Anyway, once we have
distribution between queues, we can avoid the global bg lock and global
bg limit and set that per queue. If I remember right, that would solve
the lock order issue. Although I forgot the exact details. Wish I would
have creates notes or a blog - too late now :(

> 
> Seems so, because there must be at least one background request on the
> regular request queues if bg_queue is non-empty, and when that is
> finished, a new one will be put on the pending queue, and so on until
> bg_queue becomes empty.

Yeah, in order to avoid stalls, ring queues always allow one bg request,
ignoring the global limit.

> 
> Maybe add a comment about this subtlety?

Where should that comment be?


Thanks,
Bernd