From: Bart Van Assche <bvanassche@acm.org>
To: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Cc: Damien Le Moal <dlemoal@kernel.org>,
Shinichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Subject: block/032 triggers lockdep complaint with v6.13-rc3
Date: Tue, 17 Dec 2024 14:30:29 -0800 [thread overview]
Message-ID: <e78b6e21-7b7b-40b1-8a2f-bbcfb4e794f3@acm.org> (raw)
Hi,
If I run test block/032, a lockdep complaint appears. Has anyone else
noticed this?
Thanks,
Bart.
======================================================
WARNING: possible circular locking dependency detected
6.13.0-rc3-dbg #23 Not tainted
------------------------------------------------------
check/8526 is trying to acquire lock:
ffff88811e19c458 (&q->sysfs_lock){+.+.}-{4:4}, at:
blk_unregister_queue+0xa7/0x2b0
but task is already holding lock:
ffff88811e19c018 (&q->q_usage_counter(queue)#28){++++}-{0:0}, at:
sd_remove+0x95/0x150 [sd_mod]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #2 (&q->q_usage_counter(queue)#28){++++}-{0:0}:
__lock_acquire+0xbec/0x1d90
lock_acquire.part.0+0x13b/0x390
lock_acquire+0x80/0xb0
blk_queue_enter+0x3fc/0x520
blk_mq_alloc_request+0x3dd/0x860
scsi_execute_cmd+0x3f4/0x7b0 [scsi_mod]
read_capacity_16+0x1d6/0xca0 [sd_mod]
sd_read_capacity+0x196/0xa50 [sd_mod]
sd_revalidate_disk.isra.0+0xb34/0x2090 [sd_mod]
sd_probe+0x7f7/0xe20 [sd_mod]
really_probe+0x1f4/0x8b0
__driver_probe_device+0x19a/0x380
driver_probe_device+0x4f/0x140
__device_attach_driver+0x18c/0x290
bus_for_each_drv+0x113/0x1a0
__device_attach_async_helper+0x19b/0x240
async_run_entry_fn+0x99/0x520
process_one_work+0xdd0/0x1490
worker_thread+0x5eb/0x1010
kthread+0x2e5/0x3b0
ret_from_fork+0x3a/0x80
ret_from_fork_asm+0x11/0x20
-> #1 (&q->limits_lock){+.+.}-{4:4}:
__lock_acquire+0xbec/0x1d90
lock_acquire.part.0+0x13b/0x390
lock_acquire+0x80/0xb0
__mutex_lock+0x16f/0x13b0
mutex_lock_nested+0x1f/0x30
__blk_mq_update_nr_hw_queues+0x678/0x1410
blk_mq_update_nr_hw_queues+0x31/0x40
scsi_debug_write_info+0x34/0x1b0 [scsi_debug]
zbc_show+0x3e/0x80 [scsi_debug]
configfs_write_iter+0x2cf/0x4a0
vfs_write+0x5ec/0x1220
ksys_write+0x10a/0x1f0
__x64_sys_write+0x76/0xb0
x64_sys_call+0x27f/0x17d0
do_syscall_64+0x92/0x180
entry_SYSCALL_64_after_hwframe+0x4b/0x53
-> #0 (&q->sysfs_lock){+.+.}-{4:4}:
check_prev_add+0x1b7/0x23b0
validate_chain+0xf3d/0x1d70
__lock_acquire+0xbec/0x1d90
lock_acquire.part.0+0x13b/0x390
lock_acquire+0x80/0xb0
__mutex_lock+0x16f/0x13b0
mutex_lock_nested+0x1f/0x30
blk_unregister_queue+0xa7/0x2b0
del_gendisk+0x266/0xb30
sd_remove+0x95/0x150 [sd_mod]
device_remove+0x111/0x160
device_release_driver_internal+0x3c5/0x570
device_release_driver+0x16/0x20
bus_remove_device+0x1fa/0x3e0
device_del+0x3ed/0xa20
__scsi_remove_device+0x280/0x340 [scsi_mod]
sdev_store_delete+0x8c/0x120 [scsi_mod]
dev_attr_store+0x3f/0x70
sysfs_kf_write+0x106/0x150
kernfs_fop_write_iter+0x39e/0x5a0
vfs_write+0x5ec/0x1220
ksys_write+0x10a/0x1f0
__x64_sys_write+0x76/0xb0
x64_sys_call+0x27f/0x17d0
do_syscall_64+0x92/0x180
entry_SYSCALL_64_after_hwframe+0x4b/0x53
other info that might help us debug this:
Chain exists of:
&q->sysfs_lock --> &q->limits_lock --> &q->q_usage_counter(queue)#28
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&q->q_usage_counter(queue)#28);
lock(&q->limits_lock);
lock(&q->q_usage_counter(queue)#28);
lock(&q->sysfs_lock);
*** DEADLOCK ***
5 locks held by check/8526:
#0: ffff88812e746418 (sb_writers#3){.+.+}-{0:0}, at:
ksys_write+0x10a/0x1f0
#1: ffff888189e4bc88 (&of->mutex#2){+.+.}-{4:4}, at:
kernfs_fop_write_iter+0x261/0x5a0
#2: ffff888190fee0e0 (&shost->scan_mutex){+.+.}-{4:4}, at:
sdev_store_delete+0x84/0x120 [scsi_mod]
#3: ffff88812e47a378 (&dev->mutex){....}-{4:4}, at:
device_release_driver_internal+0xaa/0x570
#4: ffff88811e19c018 (&q->q_usage_counter(queue)#28){++++}-{0:0}, at:
sd_remove+0x95/0x150 [sd_mod]
stack backtrace:
CPU: 21 UID: 0 PID: 8526 Comm: check Not tainted 6.13.0-rc3-dbg #23
65ecec9f9b5989219cd64cfc2b6ef3edbedebe25
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
1.16.3-debian-1.16.3-2 04/01/2014
Call Trace:
<TASK>
show_stack+0x4d/0x60
dump_stack_lvl+0x61/0x80
dump_stack+0x14/0x16
print_circular_bug.cold+0x39/0x43
check_noncircular+0x2f4/0x3d0
check_prev_add+0x1b7/0x23b0
validate_chain+0xf3d/0x1d70
__lock_acquire+0xbec/0x1d90
lock_acquire.part.0+0x13b/0x390
lock_acquire+0x80/0xb0
__mutex_lock+0x16f/0x13b0
mutex_lock_nested+0x1f/0x30
blk_unregister_queue+0xa7/0x2b0
del_gendisk+0x266/0xb30
sd_remove+0x95/0x150 [sd_mod 95fdb9620c9f51a5a0ad41c05aada49874bfacdd]
device_remove+0x111/0x160
device_release_driver_internal+0x3c5/0x570
device_release_driver+0x16/0x20
bus_remove_device+0x1fa/0x3e0
device_del+0x3ed/0xa20
__scsi_remove_device+0x280/0x340 [scsi_mod
bb02a8ce36abc63da71f0d4ee9a3085037ce1922]
sdev_store_delete+0x8c/0x120 [scsi_mod
bb02a8ce36abc63da71f0d4ee9a3085037ce1922]
dev_attr_store+0x3f/0x70
sysfs_kf_write+0x106/0x150
kernfs_fop_write_iter+0x39e/0x5a0
vfs_write+0x5ec/0x1220
ksys_write+0x10a/0x1f0
__x64_sys_write+0x76/0xb0
x64_sys_call+0x27f/0x17d0
do_syscall_64+0x92/0x180
entry_SYSCALL_64_after_hwframe+0x4b/0x53
next reply other threads:[~2024-12-17 22:30 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-12-17 22:30 Bart Van Assche [this message]
2024-12-17 23:35 ` block/032 triggers lockdep complaint with v6.13-rc3 Damien Le Moal
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=e78b6e21-7b7b-40b1-8a2f-bbcfb4e794f3@acm.org \
--to=bvanassche@acm.org \
--cc=dlemoal@kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=shinichiro.kawasaki@wdc.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