block/032 triggers lockdep complaint with v6.13-rc3

block/032 triggers lockdep complaint with v6.13-rc3

[Bart Van Assche]

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

Re: block/032 triggers lockdep complaint with v6.13-rc3

[Damien Le Moal]

On 2024/12/17 14:30, Bart Van Assche wrote:
> Hi,
> 
> If I run test block/032, a lockdep complaint appears. Has anyone else 
> noticed this?

This looks like the same problem Ming found:

https://lore.kernel.org/linux-block/20241216080206.2850773-1-ming.lei@redhat.com/

-- 
Damien Le Moal
Western Digital Research