From: kernel test robot <oliver.sang@intel.com>
To: Julian Sun <sunjunchao2870@gmail.com>
Cc: <oe-lkp@lists.linux.dev>, <lkp@intel.com>,
Julian Sun <sunjunchao@bytedance.com>,
<linux-block@vger.kernel.org>, <axboe@kernel.dk>,
<nilay@linux.ibm.com>, <ming.lei@redhat.com>,
<stable@vger.kernel.org>, <oliver.sang@intel.com>
Subject: Re: [PATCH v2] block: restore default wbt enablement
Date: Thu, 14 Aug 2025 16:08:00 +0800 [thread overview]
Message-ID: <202508140947.5235b2c7-lkp@intel.com> (raw)
In-Reply-To: <20250812154257.57540-1-sunjunchao@bytedance.com>
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
next prev parent reply other threads:[~2025-08-14 8:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-12 15:42 [PATCH v2] block: restore default wbt enablement Julian Sun
2025-08-13 0:41 ` Ming Lei
2025-08-13 3:27 ` Yu Kuai
2025-08-13 5:03 ` Nilay Shroff
2025-08-13 12:32 ` Jens Axboe
2025-08-14 8:08 ` kernel test robot [this message]
2025-08-14 8:40 ` Nilay Shroff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=202508140947.5235b2c7-lkp@intel.com \
--to=oliver.sang@intel.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=lkp@intel.com \
--cc=ming.lei@redhat.com \
--cc=nilay@linux.ibm.com \
--cc=oe-lkp@lists.linux.dev \
--cc=stable@vger.kernel.org \
--cc=sunjunchao2870@gmail.com \
--cc=sunjunchao@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox