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

[Jens Axboe <axboe@kernel.dk>]

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.

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.

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

-- 
Jens Axboe