Re: [bug report][bisected] kernel BUG at lib/list_debug.c:32! triggered by blktests nvme/049

[Jens Axboe <axboe@kernel.dk>]

On 1/14/26 7:11 AM, Ming Lei wrote:
> On Wed, Jan 14, 2026 at 01:58:03PM +0800, Yi Zhang wrote:
>> On Thu, Jan 8, 2026 at 2:39 PM Yi Zhang <yi.zhang@redhat.com> wrote:
>>>
>>> On Thu, Jan 8, 2026 at 12:48 AM Jens Axboe <axboe@kernel.dk> wrote:
>>>>
>>>> On 1/7/26 9:39 AM, Yi Zhang wrote:
>>>>> Hi
>>>>> The following issue[2] was triggered by blktests nvme/059 and it's
>>>>
>>>> nvme/049 presumably?
>>>>
>>> Yes.
>>>
>>>>> 100% reproduced with commit[1]. Please help check it and let me know
>>>>> if you need any info/test for it.
>>>>> Seems it's one regression, I will try to test with the latest
>>>>> linux-block/for-next and also bisect it tomorrow.
>>>>
>>>> Doesn't reproduce for me on the current tree, but nothing since:
>>>>
>>>>> commit 5ee81d4ae52ec4e9206efb4c1b06e269407aba11
>>>>> Merge: 29cefd61e0c6 fcf463b92a08
>>>>> Author: Jens Axboe <axboe@kernel.dk>
>>>>> Date:   Tue Jan 6 05:48:07 2026 -0700
>>>>>
>>>>>     Merge branch 'for-7.0/blk-pvec' into for-next
>>>>
>>>> should have impacted that. So please do bisect.
>>>
>>> Hi Jens
>>> The issue seems was introduced from below commit.
>>> and the issue cannot be reproduced after reverting this commit.
>>
>> The issue still can be reproduced on the latest linux-block/for-next
> 
> Hi Yi,
> 
> Can you try the following patch?
> 
> 
> diff --git a/drivers/nvme/host/ioctl.c b/drivers/nvme/host/ioctl.c
> index a9c097dacad6..7b0e62b8322b 100644
> --- a/drivers/nvme/host/ioctl.c
> +++ b/drivers/nvme/host/ioctl.c
> @@ -425,14 +425,23 @@ static enum rq_end_io_ret nvme_uring_cmd_end_io(struct request *req,
>  	pdu->result = le64_to_cpu(nvme_req(req)->result.u64);
>  
>  	/*
> -	 * IOPOLL could potentially complete this request directly, but
> -	 * if multiple rings are polling on the same queue, then it's possible
> -	 * for one ring to find completions for another ring. Punting the
> -	 * completion via task_work will always direct it to the right
> -	 * location, rather than potentially complete requests for ringA
> -	 * under iopoll invocations from ringB.
> +	 * For IOPOLL, complete the request inline. The request's io_kiocb
> +	 * uses a union for io_task_work and iopoll_node, so scheduling
> +	 * task_work would corrupt the iopoll_list while the request is
> +	 * still on it. io_uring_cmd_done() handles IOPOLL by setting
> +	 * iopoll_completed rather than scheduling task_work.
> +	 *
> +	 * For non-IOPOLL, complete via task_work to ensure we run in the
> +	 * submitter's context and handling multiple rings is safe.
>  	 */
> -	io_uring_cmd_do_in_task_lazy(ioucmd, nvme_uring_task_cb);
> +	if (blk_rq_is_poll(req)) {
> +		if (pdu->bio)
> +			blk_rq_unmap_user(pdu->bio);
> +		io_uring_cmd_done32(ioucmd, pdu->status, pdu->result, 0);
> +	} else {
> +		io_uring_cmd_do_in_task_lazy(ioucmd, nvme_uring_task_cb);
> +	}
> +
>  	return RQ_END_IO_FREE;
>  }
>  

Ah yes that should fix it, the task_work addition will conflict with
the list addition. Don't think it's safe though, which is why I made
them all use task_work previously. Let me fix it in the IOPOLL patch
instead.

-- 
Jens Axboe