possible race in interrupt handling

[James Harper]

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?

thanks

james