On 8/14/25 1:38 PM, kernel test robot wrote:
>
>
> Hello,
>
> kernel test robot noticed "WARNING:possible_circular_locking_dependency_detected" on:
>
> commit: 555859c514d9b8ca62ca2f1553bf6291ceee1e3a ("[PATCH v2] block: restore default wbt enablement")
> url: https://github.com/intel-lab-lkp/linux/commits/Julian-Sun/block-restore-default-wbt-enablement/20250812-234518
> base: https://git.kernel.org/cgit/linux/kernel/git/axboe/linux-block.git for-next
> patch link: https://lore.kernel.org/all/20250812154257.57540-1-sunjunchao@xxxxxxxxxxxxx/
> patch subject: [PATCH v2] block: restore default wbt enablement
>
> in testcase: boot
>
> config: i386-randconfig-012-20250813
> compiler: gcc-12
> test machine: qemu-system-i386 -enable-kvm -cpu SandyBridge -smp 2 -m 4G
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@xxxxxxxxx>
> | Closes: https://lore.kernel.org/oe-lkp/202508140947.5235b2c7-lkp@xxxxxxxxx
>
>
> [ 1.575968][ T1] WARNING: possible circular locking dependency detected
> [ 1.575968][ T1] 6.17.0-rc1-00012-g555859c514d9 #1 Tainted: G T
> [ 1.575968][ T1] ------------------------------------------------------
> [ 1.575968][ T1] swapper/0/1 is trying to acquire lock:
> [ 1.575968][ T1] 420f00b4 (cpu_hotplug_lock){++++}-{0:0}, at: static_key_slow_inc (kernel/jump_label.c:191)
> [ 1.575968][ T1]
> [ 1.575968][ T1] but task is already holding lock:
> [ 1.575968][ T1] 46342678 (&q->q_usage_counter(io)#9){++++}-{0:0}, at: blk_mq_freeze_queue_nomemsave (block/blk-mq.c:206)
> [ 1.575968][ T1]
> [ 1.575968][ T1] which lock already depends on the new lock.
> [ 1.575968][ T1]
> [ 1.575968][ T1] the existing dependency chain (in reverse order) is:
> [ 1.575968][ T1]
> [ 1.575968][ T1] -> #2 (&q->q_usage_counter(io)#9){++++}-{0:0}:
> [ 1.575968][ T1]
> [ 1.575968][ T1] -> #1 (fs_reclaim){+.+.}-{0:0}:
> [ 1.575968][ T1]
> [ 1.575968][ T1] -> #0 (cpu_hotplug_lock){++++}-{0:0}:
> [ 1.575968][ T1]
> [ 1.575968][ T1] other info that might help us debug this:
> [ 1.575968][ T1]
> [ 1.575968][ T1] Chain exists of:
> [ 1.575968][ T1] cpu_hotplug_lock --> fs_reclaim --> &q->q_usage_counter(io)#9
> [ 1.575968][ T1]
> [ 1.575968][ T1] Possible unsafe locking scenario:
> [ 1.575968][ T1]
> [ 1.575968][ T1] CPU0 CPU1
> [ 1.575968][ T1] ---- ----
> [ 1.575968][ T1] lock(&q->q_usage_counter(io)#9);
> [ 1.575968][ T1] lock(fs_reclaim);
> [ 1.575968][ T1] lock(&q->q_usage_counter(io)#9);
> [ 1.575968][ T1] rlock(cpu_hotplug_lock);
> [ 1.575968][ T1]
> [ 1.575968][ T1] *** DEADLOCK ***
This issue is already being addressed here :
https://lore.kernel.org/all/20250814082612.500845-1-nilay@xxxxxxxxxxxxx/
Thanks,
--Nilay
