Re: [PATCH] io_uring: fix IOPOLL with passthrough I/O

[Jens Axboe <axboe@kernel.dk>]

On 1/14/26 8:32 AM, Ming Lei wrote:
> On Wed, Jan 14, 2026 at 08:12:15AM -0700, Jens Axboe wrote:
>> A previous commit improving IOPOLL made an incorrect assumption that
>> task_work isn't used with IOPOLL. This can cause crashes when doing
>> passthrough I/O on nvme, where queueing the completion task_work will
>> trample on the same memory that holds the completed list of requests.
>>
>> Fix it up by shuffling the members around, so we're not sharing any
>> parts that end up getting used in this path.
>>
>> Fixes: 3c7d76d6128a ("io_uring: IOPOLL polling improvements")
>> Reported-by: Yi Zhang <yi.zhang@redhat.com>
>> Link: https://lore.kernel.org/linux-block/CAHj4cs_SLPj9v9w5MgfzHKy+983enPx3ZQY2kMuMJ1202DBefw@mail.gmail.com/
>> Signed-off-by: Jens Axboe <axboe@kernel.dk>
>>
>> ---
>>
>> diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
>> index e4c804f99c30..211686ad89fd 100644
>> --- a/include/linux/io_uring_types.h
>> +++ b/include/linux/io_uring_types.h
>> @@ -713,13 +713,10 @@ struct io_kiocb {
>>  	atomic_t			refs;
>>  	bool				cancel_seq_set;
>>  
>> -	/*
>> -	 * IOPOLL doesn't use task_work, so use the ->iopoll_node list
>> -	 * entry to manage pending iopoll requests.
>> -	 */
>>  	union {
>>  		struct io_task_work	io_task_work;
>> -		struct list_head	iopoll_node;
>> +		/* For IOPOLL setup queues, with hybrid polling */
>> +		u64                     iopoll_start;
>>  	};
>>  
>>  	union {
>> @@ -728,8 +725,8 @@ struct io_kiocb {
>>  		 * poll
>>  		 */
>>  		struct hlist_node	hash_node;
>> -		/* For IOPOLL setup queues, with hybrid polling */
>> -		u64                     iopoll_start;
>> +		/* IOPOLL completion handling */
>> +		struct list_head	iopoll_node;
>>  		/* for private io_kiocb freeing */
>>  		struct rcu_head		rcu_head;
> 
> ->hash_node is used by uring_cmd in
> io_uring_cmd_mark_cancelable()/io_uring_cmd_del_cancelable(), so this
> way may break uring_cmd if supporting iopoll and cancelable in future.

We don't support cancelation on requests that go via the block stack,
never have and probably never will. But I should make a comment about
that, just in case...

-- 
Jens Axboe