possible race in interrupt handling

[Denis Vlasenko]

On 26 February 2003 14:12, James Harper wrote:
> my system config is:
> 3 devices on irq 19 (in handler order): ens1371 (sound card), wlan0
> (wireless adapter), uhci-ucd (usb controller)
> smp system - 2 x celeron 400
>
> are either of these scenario's possible: (remember that for shared
> irq's, each handler is invoked in turn, doesn't matter which device
> generated the interrupt afaik)
>
> scenario #1
> ens1371 asserts interrupt - cpu0 handles
> cpu0 enters ens1371 handler, handles interrupt, leaves
>   (interrupt line is now clear so another interrupt can physically
> happen, cpu0 is still traversing the handler chain)
> wlan0 asserts interrupt (EV_RX) - cpu1 handles
> cpu1 enters ens1371 handler then exits (nothing to do so is quick)
> cpu0 enters wlan0 handler
> cpu1 enters wlan0 handler
> cpu0 reads EVSTAT, finding EV_RX set
> cpu1 reads EVSTAT, finding EV_RX set
>
> scenario #2
> wlan0 asserts interrupt EV_CMD - cpu0 handles
> cpu0 enters ens1371 handler then exits (nothing to do)
> cpu0 enters wlan0 handler, acks CMD thus clearing interrupt line and
> is now doing the rest of the cmd stuff
> wlan0 asserts interrupt EV_RX - cpu1 handles
> cpu1 enters ens1371 handler then exits (nothing to do)
> cpu0 loops in prism2_interrupt and reads EVSTAT, finding EV_RX set
> cpu1 enters wlan0 handler,
> cpu1 reads EVSTAT, finding EV_RX set
>
> in either scenario, both cpu0 and cpu1 are now going to want to
> launch a tasklet to handle EV_RX - all hell will break loose.
>
> of course there could be something i've missed which protects against
> this happening... but it sure would explain the periodic lockups i've
> been experiencing once i start playing sound and pushing traffic down
> the wireless card...
>
> can anyone comment?

Try to catch it in action.
Stick an atomic counter, do a cnt++ on entry,
cnt-- on exit, printk a message if you see it non zero on entry.
--
vda