rdma-for-next lockdep complaint

rdma-for-next lockdep complaint

[Bart Van Assche]

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

Re: rdma-for-next lockdep complaint

[Jason Gunthorpe]

On Fri, May 22, 2020 at 02:29:15PM -0700, Bart Van Assche wrote:
> 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?

I haven't seen it before, and it doesn't look like anything changed
here lately.

I think your test must have got unlucky to hit one of the
rdma_destroy_id paths.

It looks like a false positive from lockdep as these are never the
same lock.

Perhaps it could be fixed by lifting the mutex_unlock to before
the rdma_destroy_id ? Would need some study

Jason