diff options
author | Roland Dreier <rolandd@cisco.com> | 2007-05-19 08:51:53 -0700 |
---|---|---|
committer | Roland Dreier <rolandd@cisco.com> | 2007-05-19 08:51:53 -0700 |
commit | 8b8c8bca3a63073bac20f0fca178e00fdf7f5a09 (patch) | |
tree | 59c7f4b6a502e99e620d20d9c251fdebb79cc34a /include/rdma | |
parent | 7b82cd8ee7374f803a3daf9a6cbc6eb4bbb10a63 (diff) | |
download | linux-3.10-8b8c8bca3a63073bac20f0fca178e00fdf7f5a09.tar.gz linux-3.10-8b8c8bca3a63073bac20f0fca178e00fdf7f5a09.tar.bz2 linux-3.10-8b8c8bca3a63073bac20f0fca178e00fdf7f5a09.zip |
IB/ipath: Fix potential deadlock with multicast spinlocks
Lockdep found the following potential deadlock between mcast_lock and
n_mcast_grps_lock: mcast_lock is taken from both interrupt context and
process context, so spin_lock_irqsave() must be used to take it.
n_mcast_grps_lock is only taken from process context, so at first it
seems safe to take it with plain spin_lock(); however, it also nests
inside mcast_lock, and hence we could deadlock:
cpu A cpu B
ipath_mcast_add():
spin_lock_irq(&mcast_lock);
ipath_mcast_detach():
spin_lock(&n_mcast_grps_lock);
<enter interrupt>
ipath_mcast_find():
spin_lock_irqsave(&mcast_lock);
spin_lock(&n_mcast_grps_lock);
Fix this by using spin_lock_irq() to take n_mcast_grps_lock.
Signed-off-by: Roland Dreier <rolandd@cisco.com>
Diffstat (limited to 'include/rdma')
0 files changed, 0 insertions, 0 deletions