On 6/26/25 1:24 AM, Bart Van Assche wrote: > Every time I run test srp/002 the following deadlock is triggered: > > task:multipathd > Call Trace: > <TASK> > __schedule+0x8c1/0x1bf0 > schedule+0xdd/0x270 > schedule_preempt_disabled+0x1c/0x30 > __mutex_lock+0xb89/0x1650 > mutex_lock_nested+0x1f/0x30 > dm_table_set_restrictions+0x823/0xdf0 > __bind+0x166/0x590 > dm_swap_table+0x2a7/0x490 > do_resume+0x1b1/0x610 > dev_suspend+0x55/0x1a0 > ctl_ioctl+0x3a5/0x7e0 > dm_ctl_ioctl+0x12/0x20 > __x64_sys_ioctl+0x127/0x1a0 > x64_sys_call+0xe2b/0x17d0 > do_syscall_64+0x96/0x3a0 > entry_SYSCALL_64_after_hwframe+0x4b/0x53 > </TASK> > task:(udev-worker) > Call Trace: > <TASK> > __schedule+0x8c1/0x1bf0 > schedule+0xdd/0x270 > blk_mq_freeze_queue_wait+0xf2/0x140 > blk_mq_freeze_queue_nomemsave+0x23/0x30 > queue_ra_store+0x14e/0x290 > queue_attr_store+0x23e/0x2c0 > sysfs_kf_write+0xde/0x140 > kernfs_fop_write_iter+0x3b2/0x630 > vfs_write+0x4fd/0x1390 > ksys_write+0xfd/0x230 > __x64_sys_write+0x76/0xc0 > x64_sys_call+0x276/0x17d0 > do_syscall_64+0x96/0x3a0 > entry_SYSCALL_64_after_hwframe+0x4b/0x53 > </TASK> It seems that some other thread on your system acquired ->freeze_lock and never released it and that prevents the udev-worker thread to forward progress. As udev-worker couldn't forward progress, it also now prevents the multipathd to make progress (as multipathd is pending on ->limits_lock which has been acquired by udev-worker). If you haven't enabled lockdep on your system then can you please configure lockdep and rerun the srp/002 test? I think, you shall encounter a lockdep splat and that shall help further investigate the deadlock. Thanks, --Nilay
