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:32:42 +0000 (09:32 +0100)
commit6fa75685aa3ade4de264c06c26aa7b90cdec34f3
tree22aa72180c6f963d402042c773bb06a4cd377776
parenta13daf038b4969e4dbc3b7f0e6ed8de6440c6fd6
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