IB/usnic: Fix potential deadlock
authorParvi Kaustubhi <pkaustub@cisco.com>
Tue, 11 Dec 2018 22:15:42 +0000 (14:15 -0800)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 26 Jan 2019 08:37:06 +0000 (09:37 +0100)
commit9d3e1c0981c68e655707a3b0ab2e33e294ed40f8
tree2c1148a87c7793e34b59de6306ae50f8f160fc34
parentd9c25a6fe016afa9c511d1439db8ca5c88a7582a
IB/usnic: Fix potential deadlock

[ Upstream commit 8036e90f92aae2784b855a0007ae2d8154d28b3c ]

Acquiring the rtnl lock while holding usdev_lock could result in a
deadlock.

For example:

usnic_ib_query_port()
| mutex_lock(&us_ibdev->usdev_lock)
 | ib_get_eth_speed()
  | rtnl_lock()

rtnl_lock()
| usnic_ib_netdevice_event()
 | mutex_lock(&us_ibdev->usdev_lock)

This commit moves the usdev_lock acquisition after the rtnl lock has been
released.

This is safe to do because usdev_lock is not protecting anything being
accessed in ib_get_eth_speed(). Hence, the correct order of holding locks
(rtnl -> usdev_lock) is not violated.

Signed-off-by: Parvi Kaustubhi <pkaustub@cisco.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
drivers/infiniband/hw/usnic/usnic_ib_verbs.c