Re: [PATCH v2] block: restore default wbt enablement

[Nilay Shroff <nilay@linux.ibm.com>]

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@bytedance.com/
> 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@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202508140947.5235b2c7-lkp@intel.com
> 
> 
> [    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@linux.ibm.com/

Thanks,
--Nilay