Home
last modified time | relevance | path

Searched hist:df7fba66471c6bbbaebb55e1bb3658eb7ce00a9b (Results 1 – 2 of 2) sorted by relevance

/openbmc/linux/drivers/infiniband/hw/mlx4/
H A Dmad.cdiff df7fba66471c6bbbaebb55e1bb3658eb7ce00a9b Fri Aug 03 03:26:45 CDT 2012 Jack Morgenstein <jackm@dev.mellanox.co.il> IB/mlx4: Fix possible deadlock on sm_lock spinlock

The sm_lock spinlock is taken in the process context by
mlx4_ib_modify_device, and in the interrupt context by update_sm_ah,
so we need to take that spinlock with irqsave, and release it with
irqrestore.

Lockdeps reports this as follows:

[ INFO: inconsistent lock state ]
3.5.0+ #20 Not tainted
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&ibdev->sm_lock)->rlock){?.+...}, at: [<ffffffffa028af1d>] update_sm_ah+0xad/0x100 [mlx4_ib]
{HARDIRQ-ON-W} state was registered at:
[<ffffffff810b84a0>] mark_irqflags+0x120/0x190
[<ffffffff810b9ce7>] __lock_acquire+0x307/0x4c0
[<ffffffff810b9f51>] lock_acquire+0xb1/0x150
[<ffffffff815523b1>] _raw_spin_lock+0x41/0x50
[<ffffffffa028d563>] mlx4_ib_modify_device+0x63/0x240 [mlx4_ib]
[<ffffffffa026d1fc>] ib_modify_device+0x1c/0x20 [ib_core]
[<ffffffffa026c353>] set_node_desc+0x83/0xc0 [ib_core]
[<ffffffff8136a150>] dev_attr_store+0x20/0x30
[<ffffffff81201fd6>] sysfs_write_file+0xe6/0x170
[<ffffffff8118da38>] vfs_write+0xc8/0x190
[<ffffffff8118dc01>] sys_write+0x51/0x90
[<ffffffff8155b869>] system_call_fastpath+0x16/0x1b

...
*** DEADLOCK ***

1 lock held by swapper/0/0:

stack backtrace:
Pid: 0, comm: swapper/0 Not tainted 3.5.0+ #20
Call Trace:
<IRQ> [<ffffffff810b7bea>] print_usage_bug+0x18a/0x190
[<ffffffff810b7370>] ? print_irq_inversion_bug+0x210/0x210
[<ffffffff810b7fb2>] mark_lock_irq+0xf2/0x280
[<ffffffff810b8290>] mark_lock+0x150/0x240
[<ffffffff810b84ef>] mark_irqflags+0x16f/0x190
[<ffffffff810b9ce7>] __lock_acquire+0x307/0x4c0
[<ffffffffa028af1d>] ? update_sm_ah+0xad/0x100 [mlx4_ib]
[<ffffffff810b9f51>] lock_acquire+0xb1/0x150
[<ffffffffa028af1d>] ? update_sm_ah+0xad/0x100 [mlx4_ib]
[<ffffffff815523b1>] _raw_spin_lock+0x41/0x50
[<ffffffffa028af1d>] ? update_sm_ah+0xad/0x100 [mlx4_ib]
[<ffffffffa026b2fa>] ? ib_create_ah+0x1a/0x40 [ib_core]
[<ffffffffa028af1d>] update_sm_ah+0xad/0x100 [mlx4_ib]
[<ffffffff810c27c3>] ? is_module_address+0x23/0x30
[<ffffffffa028b05b>] handle_port_mgmt_change_event+0xeb/0x150 [mlx4_ib]
[<ffffffffa028c177>] mlx4_ib_event+0x117/0x160 [mlx4_ib]
[<ffffffff81552501>] ? _raw_spin_lock_irqsave+0x61/0x70
[<ffffffffa022718c>] mlx4_dispatch_event+0x6c/0x90 [mlx4_core]
[<ffffffffa0221b40>] mlx4_eq_int+0x500/0x950 [mlx4_core]

Reported by: Or Gerlitz <ogerlitz@mellanox.com>
Tested-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Roland Dreier <roland@purestorage.com>
H A Dmain.cdiff df7fba66471c6bbbaebb55e1bb3658eb7ce00a9b Fri Aug 03 03:26:45 CDT 2012 Jack Morgenstein <jackm@dev.mellanox.co.il> IB/mlx4: Fix possible deadlock on sm_lock spinlock

The sm_lock spinlock is taken in the process context by
mlx4_ib_modify_device, and in the interrupt context by update_sm_ah,
so we need to take that spinlock with irqsave, and release it with
irqrestore.

Lockdeps reports this as follows:

[ INFO: inconsistent lock state ]
3.5.0+ #20 Not tainted
inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
swapper/0/0 [HC1[1]:SC0[0]:HE0:SE1] takes:
(&(&ibdev->sm_lock)->rlock){?.+...}, at: [<ffffffffa028af1d>] update_sm_ah+0xad/0x100 [mlx4_ib]
{HARDIRQ-ON-W} state was registered at:
[<ffffffff810b84a0>] mark_irqflags+0x120/0x190
[<ffffffff810b9ce7>] __lock_acquire+0x307/0x4c0
[<ffffffff810b9f51>] lock_acquire+0xb1/0x150
[<ffffffff815523b1>] _raw_spin_lock+0x41/0x50
[<ffffffffa028d563>] mlx4_ib_modify_device+0x63/0x240 [mlx4_ib]
[<ffffffffa026d1fc>] ib_modify_device+0x1c/0x20 [ib_core]
[<ffffffffa026c353>] set_node_desc+0x83/0xc0 [ib_core]
[<ffffffff8136a150>] dev_attr_store+0x20/0x30
[<ffffffff81201fd6>] sysfs_write_file+0xe6/0x170
[<ffffffff8118da38>] vfs_write+0xc8/0x190
[<ffffffff8118dc01>] sys_write+0x51/0x90
[<ffffffff8155b869>] system_call_fastpath+0x16/0x1b

...
*** DEADLOCK ***

1 lock held by swapper/0/0:

stack backtrace:
Pid: 0, comm: swapper/0 Not tainted 3.5.0+ #20
Call Trace:
<IRQ> [<ffffffff810b7bea>] print_usage_bug+0x18a/0x190
[<ffffffff810b7370>] ? print_irq_inversion_bug+0x210/0x210
[<ffffffff810b7fb2>] mark_lock_irq+0xf2/0x280
[<ffffffff810b8290>] mark_lock+0x150/0x240
[<ffffffff810b84ef>] mark_irqflags+0x16f/0x190
[<ffffffff810b9ce7>] __lock_acquire+0x307/0x4c0
[<ffffffffa028af1d>] ? update_sm_ah+0xad/0x100 [mlx4_ib]
[<ffffffff810b9f51>] lock_acquire+0xb1/0x150
[<ffffffffa028af1d>] ? update_sm_ah+0xad/0x100 [mlx4_ib]
[<ffffffff815523b1>] _raw_spin_lock+0x41/0x50
[<ffffffffa028af1d>] ? update_sm_ah+0xad/0x100 [mlx4_ib]
[<ffffffffa026b2fa>] ? ib_create_ah+0x1a/0x40 [ib_core]
[<ffffffffa028af1d>] update_sm_ah+0xad/0x100 [mlx4_ib]
[<ffffffff810c27c3>] ? is_module_address+0x23/0x30
[<ffffffffa028b05b>] handle_port_mgmt_change_event+0xeb/0x150 [mlx4_ib]
[<ffffffffa028c177>] mlx4_ib_event+0x117/0x160 [mlx4_ib]
[<ffffffff81552501>] ? _raw_spin_lock_irqsave+0x61/0x70
[<ffffffffa022718c>] mlx4_dispatch_event+0x6c/0x90 [mlx4_core]
[<ffffffffa0221b40>] mlx4_eq_int+0x500/0x950 [mlx4_core]

Reported by: Or Gerlitz <ogerlitz@mellanox.com>
Tested-by: Bart Van Assche <bvanassche@acm.org>
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Roland Dreier <roland@purestorage.com>