The commit 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") protected wbt_enable_default() with q->elevator_lock; however, it also placed wbt_enable_default() before blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);, resulting in wbt failing to be enabled.
Moreover, the protection of wbt_enable_default() by q->elevator_lock was removed in commit 78c271344b6f ("block: move wbt_enable_default() out of queue freezing from sched ->exit()"), so we can directly fix this issue by placing wbt_enable_default() after blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);.
Additionally, this issue also causes the inability to read the wbt_lat_usec file, and the scenario is as follows:
root@q:/sys/block/sda/queue# cat wbt_lat_usec cat: wbt_lat_usec: Invalid argument
root@q:/data00/sjc/linux# ls /sys/kernel/debug/block/sda/rqos cannot access '/sys/kernel/debug/block/sda/rqos': No such file or directory
root@q:/data00/sjc/linux# find /sys -name wbt /sys/kernel/debug/tracing/events/wbt
After testing with this patch, wbt can be enabled normally.
Signed-off-by: Julian Sun sunjunchao@bytedance.com Cc: stable@vger.kernel.org Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") ---
Changed in v2: - Improved commit message and comment - Added Fixes and Cc stable
block/blk-sysfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/block/blk-sysfs.c b/block/blk-sysfs.c index 396cded255ea..979f01bbca01 100644 --- a/block/blk-sysfs.c +++ b/block/blk-sysfs.c @@ -903,9 +903,9 @@ int blk_register_queue(struct gendisk *disk)
if (queue_is_mq(q)) elevator_set_default(q); - wbt_enable_default(disk);
blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q); + wbt_enable_default(disk);
/* Now everything is ready and send out KOBJ_ADD uevent */ kobject_uevent(&disk->queue_kobj, KOBJ_ADD);
On Tue, Aug 12, 2025 at 11:42:57PM +0800, Julian Sun wrote:
The commit 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") protected wbt_enable_default() with q->elevator_lock; however, it also placed wbt_enable_default() before blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);, resulting in wbt failing to be enabled.
Moreover, the protection of wbt_enable_default() by q->elevator_lock was removed in commit 78c271344b6f ("block: move wbt_enable_default() out of queue freezing from sched ->exit()"), so we can directly fix this issue by placing wbt_enable_default() after blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);.
Additionally, this issue also causes the inability to read the wbt_lat_usec file, and the scenario is as follows:
root@q:/sys/block/sda/queue# cat wbt_lat_usec cat: wbt_lat_usec: Invalid argument
root@q:/data00/sjc/linux# ls /sys/kernel/debug/block/sda/rqos cannot access '/sys/kernel/debug/block/sda/rqos': No such file or directory
root@q:/data00/sjc/linux# find /sys -name wbt /sys/kernel/debug/tracing/events/wbt
After testing with this patch, wbt can be enabled normally.
Signed-off-by: Julian Sun sunjunchao@bytedance.com Cc: stable@vger.kernel.org Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock")
Looks fine,
Reviewed-by: Ming Lei ming.lei@redhat.com
Thanks, Ming
Hi,
在 2025/08/12 23:42, Julian Sun 写道:
The commit 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") protected wbt_enable_default() with q->elevator_lock; however, it also placed wbt_enable_default() before blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);, resulting in wbt failing to be enabled.
Moreover, the protection of wbt_enable_default() by q->elevator_lock was removed in commit 78c271344b6f ("block: move wbt_enable_default() out of queue freezing from sched ->exit()"), so we can directly fix this issue by placing wbt_enable_default() after blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);.
Additionally, this issue also causes the inability to read the wbt_lat_usec file, and the scenario is as follows:
root@q:/sys/block/sda/queue# cat wbt_lat_usec cat: wbt_lat_usec: Invalid argument
root@q:/data00/sjc/linux# ls /sys/kernel/debug/block/sda/rqos cannot access '/sys/kernel/debug/block/sda/rqos': No such file or directory
root@q:/data00/sjc/linux# find /sys -name wbt /sys/kernel/debug/tracing/events/wbt
After testing with this patch, wbt can be enabled normally.
Signed-off-by: Julian Sunsunjunchao@bytedance.com Cc:stable@vger.kernel.org Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock")
Usually we put the fix tag before Signed-off-by, however, this is negligible.
Reviewed-by: Yu Kuai yukuai3@huawei.com
On 8/12/25 9:12 PM, Julian Sun wrote:
The commit 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") protected wbt_enable_default() with q->elevator_lock; however, it also placed wbt_enable_default() before blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);, resulting in wbt failing to be enabled.
Moreover, the protection of wbt_enable_default() by q->elevator_lock was removed in commit 78c271344b6f ("block: move wbt_enable_default() out of queue freezing from sched ->exit()"), so we can directly fix this issue by placing wbt_enable_default() after blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);.
Additionally, this issue also causes the inability to read the wbt_lat_usec file, and the scenario is as follows:
root@q:/sys/block/sda/queue# cat wbt_lat_usec cat: wbt_lat_usec: Invalid argument
root@q:/data00/sjc/linux# ls /sys/kernel/debug/block/sda/rqos cannot access '/sys/kernel/debug/block/sda/rqos': No such file or directory
root@q:/data00/sjc/linux# find /sys -name wbt /sys/kernel/debug/tracing/events/wbt
After testing with this patch, wbt can be enabled normally.
Signed-off-by: Julian Sun sunjunchao@bytedance.com Cc: stable@vger.kernel.org Fixes: 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock")
Looks good to me: Reviewed-by: Nilay Shroff nilay@linux.ibm.com
On Tue, 12 Aug 2025 23:42:57 +0800, Julian Sun wrote:
The commit 245618f8e45f ("block: protect wbt_lat_usec using q->elevator_lock") protected wbt_enable_default() with q->elevator_lock; however, it also placed wbt_enable_default() before blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);, resulting in wbt failing to be enabled.
Moreover, the protection of wbt_enable_default() by q->elevator_lock was removed in commit 78c271344b6f ("block: move wbt_enable_default() out of queue freezing from sched ->exit()"), so we can directly fix this issue by placing wbt_enable_default() after blk_queue_flag_set(QUEUE_FLAG_REGISTERED, q);.
[...]
Applied, thanks!
[1/1] block: restore default wbt enablement commit: 8f5845e0743bf3512b71b3cb8afe06c192d6acc4
Best regards,
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-defa... 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 *** [ 1.575968][ T1] [ 1.575968][ T1] 5 locks held by swapper/0/1: [ 1.575968][ T1] #0: 43d11208 (&set->update_nr_hwq_lock){.+.+}-{4:4}, at: add_disk_fwnode (block/genhd.c:597) [ 1.575968][ T1] #1: 463429c8 (&q->sysfs_lock){+.+.}-{4:4}, at: blk_register_queue (block/blk-sysfs.c:889) [ 1.575968][ T1] #2: 463427e0 (&q->rq_qos_mutex){+.+.}-{4:4}, at: wbt_init (block/blk-wbt.c:925) [ 1.575968][ T1] #3: 46342678 (&q->q_usage_counter(io)#9){++++}-{0:0}, at: blk_mq_freeze_queue_nomemsave (block/blk-mq.c:206) [ 1.575968][ T1] #4: 46342694 (&q->q_usage_counter(queue)){+.+.}-{0:0}, at: blk_mq_freeze_queue_nomemsave (block/blk-mq.c:206) [ 1.575968][ T1] [ 1.575968][ T1] stack backtrace: [ 1.575968][ T1] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G T 6.17.0-rc1-00012-g555859c514d9 #1 PREEMPT(none) [ 1.575968][ T1] Tainted: [T]=RANDSTRUCT [ 1.575968][ T1] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 [ 1.575968][ T1] Call Trace: [ 1.575968][ T1] ? dump_stack_lvl (lib/dump_stack.c:123) [ 1.575968][ T1] ? dump_stack (lib/dump_stack.c:130) [ 1.575968][ T1] ? print_circular_bug (kernel/locking/lockdep.c:2045) [ 1.575968][ T1] ? check_noncircular (kernel/locking/lockdep.c:2175) [ 1.575968][ T1] ? check_prev_add (kernel/locking/lockdep.c:3166) [ 1.575968][ T1] ? validate_chain (kernel/locking/lockdep.c:3285 kernel/locking/lockdep.c:3908) [ 1.575968][ T1] ? __lock_acquire (kernel/locking/lockdep.c:5237) [ 1.575968][ T1] ? lock_acquire (kernel/locking/lockdep.c:470 kernel/locking/lockdep.c:5870 kernel/locking/lockdep.c:5825) [ 1.575968][ T1] ? static_key_slow_inc (kernel/jump_label.c:191) [ 1.575968][ T1] ? cpus_read_lock (arch/x86/include/asm/preempt.h:80 include/linux/percpu-rwsem.h:55 include/linux/percpu-rwsem.h:77 kernel/cpu.c:491) [ 1.575968][ T1] ? static_key_slow_inc (kernel/jump_label.c:191) [ 1.575968][ T1] ? rq_qos_add (include/linux/blk-mq.h:940 block/blk-rq-qos.c:351) [ 1.575968][ T1] ? wbt_init (block/blk-wbt.c:925) [ 1.575968][ T1] ? wbt_enable_default (block/blk-wbt.c:728) [ 1.575968][ T1] ? blk_register_queue (block/blk-sysfs.c:910) [ 1.575968][ T1] ? __add_disk (block/genhd.c:528) [ 1.575968][ T1] ? add_disk_fwnode (block/genhd.c:597) [ 1.575968][ T1] ? device_add_disk (block/genhd.c:628) [ 1.575968][ T1] ? loop_add (drivers/block/loop.c:2078 (discriminator 3)) [ 1.575968][ T1] ? __lock_acquire (kernel/locking/lockdep.c:5237) [ 1.575968][ T1] ? loop_init (drivers/block/loop.c:2268 (discriminator 3)) [ 1.575968][ T1] ? max_loop_setup (drivers/block/loop.c:2228) [ 1.575968][ T1] ? do_one_initcall (init/main.c:1269) [ 1.575968][ T1] ? do_initcalls (init/main.c:1330 init/main.c:1347) [ 1.575968][ T1] ? kernel_init_freeable (init/main.c:1583) [ 1.575968][ T1] ? rest_init (init/main.c:1461) [ 1.575968][ T1] ? kernel_init (init/main.c:1471) [ 1.575968][ T1] ? ret_from_fork (arch/x86/kernel/process.c:154) [ 1.575968][ T1] ? rest_init (init/main.c:1461) [ 1.575968][ T1] ? ret_from_fork_asm (arch/x86/entry/entry_32.S:737) [ 1.575968][ T1] ? entry_INT80_32 (arch/x86/entry/entry_32.S:945)
The kernel config and materials to reproduce are available at: https://download.01.org/0day-ci/archive/20250814/202508140947.5235b2c7-lkp@i...
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-defa... 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
linux-stable-mirror@lists.linaro.org
-
Jens Axboe -
Julian Sun -
kernel test robot -
Ming Lei -
Nilay Shroff -
Yu Kuai