summaryrefslogtreecommitdiff
path: root/arch/xtensa/boot
diff options
context:
space:
mode:
authorFinn Thain <fthain@telegraphics.com.au>2018-01-14 01:44:31 +0300
committerGeert Uytterhoeven <geert@linux-m68k.org>2018-01-16 18:52:17 +0300
commit317b749e37789ecb3366f304dab905a97e650b41 (patch)
tree4d7e2bdce5071cff3bba1fc6dc7eb07534308745 /arch/xtensa/boot
parent7f86c765a6a2bb837c45f11526176125ff50e21f (diff)
downloadlinux-317b749e37789ecb3366f304dab905a97e650b41.tar.xz
m68k/mac: Fix race conditions in OSS interrupt dispatch
The interrupt dispatch algorithm used in the OSS driver seems to be subject to race conditions: an IRQ flag could be lost if asserted between the MOV instructions from and to the interrupt flag register. But testing shows that the write to the flag register has no effect, so rewrite the algorithm without the theoretical race condition. There is a second theoretical race condition here. When oss_irq() is called with say, IPL == 2 it will invoke the SCSI interrupt handler. The SCSI IRQ is then cleared by the mac_scsi driver. If SCSI and NuBus IRQs are now asserted together, oss_irq() will be invoked with IPL == 3 and the mac_scsi interrupt handler can be re-entered. This re-entrance issue is not limited to SCSI and could affect NuBus and ADB drivers too. Fix it by splitting up oss_irq() into separate handlers for each IPL. No-one seems to know how OSS irq flags can be cleared, if at all, so add a comment to this effect (actually reinstate one I previously removed). Testing showed that a slot IRQ with no handler can remain asserted (in this case a Radius video card) without causing problems for other IRQs. Tested-by: Stan Johnson <userm57@yahoo.com> Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Diffstat (limited to 'arch/xtensa/boot')
0 files changed, 0 insertions, 0 deletions