On Wed, Aug 08, 2012 at 05:00:39PM +0200, Felix Fietkau wrote: > On 2012-08-08 4:43 PM, Rajkumar Manoharan wrote: > > On Wed, Aug 08, 2012 at 04:25:03PM +0200, Felix Fietkau wrote: > >> commit b74713d04effbacd3d126ce94cec18742187b6ce > >> "ath9k: Handle fatal interrupts properly" introduced a race condition, where > >> IRQs are being left enabled, however the irq handler returns IRQ_HANDLED > >> while the reset is still queued without addressing the IRQ cause. > >> This leads to an IRQ storm that prevents the system from even getting to > >> the reset code. > >> > >> Fix this by disabling IRQs in the handler without touching intr_ref_cnt. > >> > > It is safer not to re-enable interrupts on FATAL errors rather than enabling > > it and then checking it on irq for bailing out. It would be better if you kill > > the interrupts on processing fatal interrupts. > A fatal interrupt isn't the only place where this is race shows up. > Anything that queues a reset is affected, so skipping the interrupt > enable in the IRQ handler is not enough (aside from the fact that it > would mess up irq disable refcounting). > > Also, how is it safer? It's not like the interrupt handler does any real > processing before running into that check. > Agree. I confused with the mentioned commit subject. Sorry for the noise. -Rajkumar -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
