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

[Keith Busch]

On Sat, Aug 29, 2026 at 05:16:00PM -0700, Bart Van Assche wrote:
> On 8/28/26 10:31 PM, syzbot wrote:
> > kernel BUG at lib/list_debug.c:34!
> > Call trace:
> >   __list_add_valid_or_report+0x144/0x148 lib/list_debug.c:32 (P)
> >   __list_add_valid include/linux/list.h:96 [inline]
> >   __list_add include/linux/list.h:158 [inline]
> >   list_add_tail include/linux/list.h:191 [inline]
> >   blk_mq_request_bypass_insert+0x130/0x1cc block/blk-mq.c:2551
> >   blk_mq_requeue_work+0x3a4/0x52c block/blk-mq.c:1560
> >   process_one_work kernel/workqueue.c:3322 [inline]
> >   process_scheduled_works+0x788/0x10b8 kernel/workqueue.c:3405
> >   worker_thread+0x798/0xbd0 kernel/workqueue.c:3486
> >   kthread+0x304/0x3d4 kernel/kthread.c:436
> >   ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:838
> 
> If my AI assistant got it right the root cause of this issue is as
> follows (I haven't tried to verify this):
> * Concurrent calls of nvme_reset_work() and blk_mq_requeue_work().
> * nvme_decide_disposition() does not check NVME_REQ_CANCELLED for
>   non-multipath requests and returns RETRY instead of COMPLETE.

We want to be able to retry eligible commands that were caught in the
crossfire of a controller reset.