Re: [RFC PATCH 2/2] io_uring: fix io may accumulation in poll mode

["Diangang Li" <lidiangang@bytedance.com>]

On 2025/12/13 04:09, Jens Axboe wrote:
> On 12/12/25 6:32 AM, Diangang Li wrote:
>>> @@ -1327,17 +1326,12 @@ int io_do_iopoll(struct io_ring_ctx *ctx, bool force_nonspin)
>>>    	if (ctx->poll_multi_queue || force_nonspin)
>>>    		poll_flags |= BLK_POLL_ONESHOT;
>>>    
>>> +	/*
>>> +	 * Loop over uncompleted polled IO requests, and poll for them.
>>> +	 */
>>>    	list_for_each_entry(req, &ctx->iopoll_list, iopoll_node) {
>>>    		int ret;
>>>    
>>> -		/*
>>> -		 * Move completed and retryable entries to our local lists.
>>> -		 * If we find a request that requires polling, break out
>>> -		 * and complete those lists first, if we have entries there.
>>> -		 */
>>> -		if (READ_ONCE(req->iopoll_completed))
>>> -			break;
>>
>> Suggest keeping iopoll_completed here to avoid unnecessary subsequent
>> polling and to process IRQ-completed requests promptly.
> 
> There should not be any IRQ completed requests in here. The block layer
> used to allow that, but that should no longer be the case. If it's a
> polled request, then it will by definition end up in a polled queue and
> need iopoll completion. Or it'll sit for a while and be completed by a
> timeout. If someone is still allowing polled IO with IRQ completions
> then that should be fixed, and there's no reason why we should try and
> catch those cases here. Will not happen with NVMe, for example.
> 

Hi Jens,

Before commit 958148a6ac06 ("block: check BLK_FEAT_POLL under 
q_usage_count"), if IORING_SETUP_IOPOLL was set, IO would still proceed 
even with zero poll queue. It would be redirected to default queues and 
still linked to ctx->iopoll_list. After that commit, these cases return 
BLK_STS_NOTSUPP.

While tests show the split path still exits: a split clears REQ_POLLED 
and sends the child to the default queue, yet the IO remains on 
iopoll_list. Is this the situation you’re referring to previously in our 
original patch with doubly-linked lists, that it's not necessarily safe 
to manipulating the list in io_complete_rw_iopoll?

> For the other point, there's no way for ->iopoll_completed to be set
> before iob.complete(&iob) has been called to invoke the callback, which
> in turn sets it. Hence there's no way for us to end up in this loop and
> have ->iopoll_completed set.
> 

Also, blk_mq_add_to_batch may return false for various reasons, so it's 
possible that the IO may complete earlier before we end up poll loop.

> So no, I don't think we need it, and honestly it wasn't even really
> needed the posted changes either.
> 



Best,
Diangang