blktests failures with v6.19 kernel
Daniel Wagner
dwagner at suse.de
Fri Feb 13 01:56:11 PST 2026
On Fri, Feb 13, 2026 at 07:57:58AM +0000, Shinichiro Kawasaki wrote:
> [3] lockdep WARN during nvme/058 with fc transport
>
> [ 409.028219] [ T95] ============================================
> [ 409.029133] [ T95] WARNING: possible recursive locking detected
> [ 409.030058] [ T95] 6.19.0+ #575 Not tainted
> [ 409.030892] [ T95] --------------------------------------------
> [ 409.031801] [ T95] kworker/u16:9/95 is trying to acquire lock:
> [ 409.032691] [ T95] ffff88813ba54948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: touch_wq_lockdep_map+0x7e/0x1a0
> [ 409.033869] [ T95]
> but task is already holding lock:
> [ 409.035254] [ T95] ffff88813ba54948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0xeef/0x1480
> [ 409.036383] [ T95]
> other info that might help us debug this:
> [ 409.037769] [ T95] Possible unsafe locking scenario:
>
> [ 409.039113] [ T95] CPU0
> [ 409.039781] [ T95] ----
> [ 409.040406] [ T95] lock((wq_completion)nvmet-wq);
> [ 409.041154] [ T95] lock((wq_completion)nvmet-wq);
> [ 409.041898] [ T95]
> *** DEADLOCK ***
>
> [ 409.043609] [ T95] May be due to missing lock nesting notation
>
> [ 409.044960] [ T95] 3 locks held by kworker/u16:9/95:
> [ 409.045721] [ T95] #0: ffff88813ba54948 ((wq_completion)nvmet-wq){+.+.}-{0:0}, at: process_one_work+0xeef/0x1480
> [ 409.046845] [ T95] #1: ffff888109797ca8 ((work_completion)(&assoc->del_work)){+.+.}-{0:0}, at: process_one_work+0x7e4/0x1480
> [ 409.048063] [ T95] #2: ffffffffac481480 (rcu_read_lock){....}-{1:3}, at: __flush_work+0xe3/0xc70
> [ 409.049128] [ T95]
> stack backtrace:
> [ 409.050366] [ T95] CPU: 1 UID: 0 PID: 95 Comm: kworker/u16:9 Not tainted 6.19.0+ #575 PREEMPT(voluntary)
> [ 409.050370] [ T95] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-4.fc42 04/01/2014
> [ 409.050373] [ T95] Workqueue: nvmet-wq nvmet_fc_delete_assoc_work [nvmet_fc]
> [ 409.050384] [ T95] Call Trace:
> [ 409.050386] [ T95] <TASK>
> [ 409.050388] [ T95] dump_stack_lvl+0x6a/0x90
> [ 409.050393] [ T95] print_deadlock_bug.cold+0xc0/0xcd
> [ 409.050401] [ T95] __lock_acquire+0x1312/0x2230
> [ 409.050408] [ T95] ? lockdep_unlock+0x5e/0xc0
> [ 409.050410] [ T95] ? __lock_acquire+0xd03/0x2230
> [ 409.050413] [ T95] lock_acquire+0x170/0x300
> [ 409.050415] [ T95] ? touch_wq_lockdep_map+0x7e/0x1a0
> [ 409.050418] [ T95] ? __flush_work+0x4e8/0xc70
> [ 409.050420] [ T95] ? find_held_lock+0x2b/0x80
> [ 409.050423] [ T95] ? touch_wq_lockdep_map+0x7e/0x1a0
> [ 409.050425] [ T95] touch_wq_lockdep_map+0x97/0x1a0
> [ 409.050428] [ T95] ? touch_wq_lockdep_map+0x7e/0x1a0
> [ 409.050430] [ T95] ? __flush_work+0x4e8/0xc70
> [ 409.050432] [ T95] __flush_work+0x5c1/0xc70
> [ 409.050434] [ T95] ? __pfx___flush_work+0x10/0x10
> [ 409.050436] [ T95] ? __pfx___flush_work+0x10/0x10
> [ 409.050439] [ T95] ? __pfx_wq_barrier_func+0x10/0x10
> [ 409.050444] [ T95] ? __pfx___might_resched+0x10/0x10
> [ 409.050454] [ T95] nvmet_ctrl_free+0x2e9/0x810 [nvmet]
> [ 409.050474] [ T95] ? __pfx___cancel_work+0x10/0x10
> [ 409.050479] [ T95] ? __pfx_nvmet_ctrl_free+0x10/0x10 [nvmet]
> [ 409.050498] [ T95] nvmet_cq_put+0x136/0x180 [nvmet]
> [ 409.050515] [ T95] nvmet_fc_target_assoc_free+0x398/0x2040 [nvmet_fc]
> [ 409.050522] [ T95] ? __pfx_nvmet_fc_target_assoc_free+0x10/0x10 [nvmet_fc]
> [ 409.050528] [ T95] nvmet_fc_delete_assoc_work.cold+0x82/0xff [nvmet_fc]
> [ 409.050533] [ T95] process_one_work+0x868/0x1480
> [ 409.050538] [ T95] ? __pfx_process_one_work+0x10/0x10
> [ 409.050541] [ T95] ? lock_acquire+0x170/0x300
> [ 409.050545] [ T95] ? assign_work+0x156/0x390
> [ 409.050548] [ T95] worker_thread+0x5ee/0xfd0
> [ 409.050553] [ T95] ? __pfx_worker_thread+0x10/0x10
> [ 409.050555] [ T95] kthread+0x3af/0x770
> [ 409.050560] [ T95] ? lock_acquire+0x180/0x300
> [ 409.050563] [ T95] ? __pfx_kthread+0x10/0x10
> [ 409.050565] [ T95] ? __pfx_kthread+0x10/0x10
> [ 409.050568] [ T95] ? ret_from_fork+0x6e/0x810
> [ 409.050576] [ T95] ? lock_release+0x1ab/0x2f0
> [ 409.050578] [ T95] ? rcu_is_watching+0x11/0xb0
> [ 409.050582] [ T95] ? __pfx_kthread+0x10/0x10
> [ 409.050585] [ T95] ret_from_fork+0x55c/0x810
> [ 409.050588] [ T95] ? __pfx_ret_from_fork+0x10/0x10
> [ 409.050590] [ T95] ? __switch_to+0x10a/0xda0
> [ 409.050598] [ T95] ? __switch_to_asm+0x33/0x70
> [ 409.050602] [ T95] ? __pfx_kthread+0x10/0x10
> [ 409.050605] [ T95] ret_from_fork_asm+0x1a/0x30
> [ 409.050610] [ T95] </TASK>
nvmet_fc_target_assoc_free runs in the nvmet_wq context and calls
nvmet_fc_delete_target_queue
nvmet_cq_put
nvmet_cq_destroy
nvmet_ctrl_put
nvmet_ctrl_free
flush_work(&ctrl->async_event_work);
cancel_work_sync(&ctrl->fatal_err_work);
The async_event_work could be running on nvmet_wq. So this deadlock is
real. No idea how to fix it yet.
> [4] WARN during nvme/058 fc transport
>
> [ 1410.913156] [ T1369] WARNING: block/genhd.c:463 at __add_disk+0x87b/0xd50, CPU#0: kworker/u16:12/1369
/*
* If the driver provides an explicit major number it also must provide
* the number of minors numbers supported, and those will be used to
* setup the gendisk.
* Otherwise just allocate the device numbers for both the whole device
* and all partitions from the extended dev_t space.
*/
ret = -EINVAL;
if (disk->major) {
if (WARN_ON(!disk->minors))
goto out;
If I read the correct, the gendisk is allocated in nvme_mpath_alloc_disk
and then added due the ANA change in nvme_update_ana_state. Not sure if
this is really fc related but I haven't really figured out how this part
of the code yet.
More information about the Linux-nvme
mailing list