[PATCH v2] block: restore default wbt enablement

[PATCH v2] block: restore default wbt enablement

[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 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);
-- 
2.39.5

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

[Ming Lei]

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

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

[Yu Kuai]

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 Sun<sunjunchao@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>

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

[Nilay Shroff]

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>

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

[Jens Axboe]

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,
-- 
Jens Axboe

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

[kernel test robot]

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 ***
[    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@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

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

[Nilay Shroff]

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