[ofa-general] ipath irq bug

[Roland Dreier]

 > [ 2651.241648]  [<ffffffff80478444>] _spin_unlock_irq+0x28/0x2d
 > [ 2651.247482]  [<ffffffff880a0769>] :ib_ipath:ipath_rc_rcv+0xf5b/0xf8e
 > [ 2651.254058]  [<ffffffff8809d1ff>] :ib_ipath:ipath_lookup_qpn+0x4f/0x5a
 > [ 2651.260791]  [<ffffffff880a5f40>] :ib_ipath:ipath_qp_rcv+0x45/0x4e
 > [ 2651.267203]  [<ffffffff880a60b3>] :ib_ipath:ipath_ib_rcv+0x16a/0x1a8
 > [ 2651.273784]  [<ffffffff88090a3e>] :ib_ipath:ipath_kreceive+0x42f/0x6b9
 > [ 2651.286397]  [<ffffffff880a6b02>] :ib_ipath:ipath_ib_piobufavail+0x72/0x79
 > [ 2651.321572]  [<ffffffff8809932c>] :ib_ipath:ipath_intr+0x26a/0x17b6

[edited slightly]

It looks like ipath_intr() (presumably the interrupt handler) ends up
in ipath_rc_rcv() and in particular in ipath_rc_rcv_error() (which is
inlined), which calls spin_unlock_irq() from interrupt context, which
is the problem.

Someone who knows the driver better than I would have to confirm this
analysis, and decide whether the fix is just to switch to
spin_lock_irqsave() in ipath_rc_rcv_error(), or if it needs to be more
elaborate.

 - R.