possible race in interrupt handling

[James Harper]

i thought of that just after i sent this. i tried it a bit later and 
nothing, dammit. crashes all over the place but no 'you are in this 
interrupt routine twice' messages :(

oh well... i'll look elsewhere

thanks

james



Denis Vlasenko wrote:

>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
>
>  
>