Hi,
If I run test srp/015 from the blktests test suite then the lockdep complaint
shown below is reported. Since I haven't seen this complaint in the past I
think that this is a regression. This complaint was triggered by the code on
the for-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma.git. Is this a known
issue?
Thanks,
Bart.
============================================
WARNING: possible recursive locking detected
5.7.0-rc1-dbg+ #1 Not tainted
--------------------------------------------
kworker/u16:3/169 is trying to acquire lock:
ffff8881e54803b8 (&id_priv->handler_mutex){+.+.}-{3:3}, at: rdma_destroy_id+0xb7/0x610 [rdma_cm]
but task is already holding lock:
ffff8881e6af03b8 (&id_priv->handler_mutex){+.+.}-{3:3}, at: iw_conn_req_handler+0x147/0x760 [rdma_cm]
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(&id_priv->handler_mutex);
lock(&id_priv->handler_mutex);
*** DEADLOCK ***
May be due to missing lock nesting notation
3 locks held by kworker/u16:3/169:
#0: ffff8881e2a8a938 ((wq_completion)iw_cm_wq){+.+.}-{0:0}, at: process_one_work+0x48b/0xb70
#1: ffffc90000457dd8 ((work_completion)(&work->work)#4){+.+.}-{0:0}, at: process_one_work+0x48f/0xb70
#2: ffff8881e6af03b8 (&id_priv->handler_mutex){+.+.}-{3:3}, at: iw_conn_req_handler+0x147/0x760 [rdma_cm]
stack backtrace:
CPU: 3 PID: 169 Comm: kworker/u16:3 Not tainted 5.7.0-rc1-dbg+ #1
Workqueue: iw_cm_wq cm_work_handler [iw_cm]
Call Trace:
dump_stack+0xa5/0xe6
validate_chain.cold+0x182/0x187
__lock_acquire+0x7db/0xee0
lock_acquire+0x198/0x630
__mutex_lock+0x12e/0xe60
mutex_lock_nested+0x1f/0x30
rdma_destroy_id+0xb7/0x610 [rdma_cm]
iw_conn_req_handler+0x50b/0x760 [rdma_cm]
cm_work_handler+0xe28/0x1080 [iw_cm]
process_one_work+0x586/0xb70
worker_thread+0x7a/0x5d0
kthread+0x211/0x240
ret_from_fork+0x24/0x30
