Re: [syzbot] [block?] BUG: corrupted list in blk_mq_request_bypass_insert

[Keith Busch]

On Mon, Aug 31, 2026 at 01:55:37PM -0700, Bart Van Assche wrote:
> On 8/31/26 7:58 AM, Keith Busch wrote:
> > We want to be able to retry eligible commands that were caught in the
> > crossfire of a controller reset.
> 
> Got it. Is my understanding correct that the NVMe driver may trigger the
> following call chain for a request that is already on the hctx dispatch
> list?
> 
> nvme_cancel_tagset()
>   blk_mq_tagset_busy_iter()
>     nvme_cancel_request()
>       nvme_pci_complete_rq()
>         nvme_complete_rq()
>           nvme_retry_req()
>             blk_mq_requeue_request()
>               spin_lock_irqsave(&q->requeue_lock, flags);
>               list_add_tail(&rq->queuelist, &q->requeue_list);
>               spin_unlock_irqrestore(&q->requeue_lock, flags);
> 
> Can this scenario trigger the list corruption reported by syzbot?

The list corruption is from inserting the same element into the list
twice, right? It could happen if the cancel request's completion raced
with a natural completion with a retryable error. We don't cancel until
bus master and interrupts are disabled on the device though, so it
shouldn't be possible for a completion to be posted after that. The bug
report indicates there may be a gap here.