Re: [RFC] IRQ handlers run with some high-priority interrupts(not NMI) enabled on some platform

[Michael Schmitz]

On 19/02/21 12:19 am, Arnd Bergmann wrote:

> drivers/net/ethernet/8390/apne.c
> drivers/net/ethernet/8390/ax88796.c
> drivers/net/ethernet/8390/hydra.c
> drivers/net/ethernet/8390/mac8390.c
> drivers/net/ethernet/8390/ne.c
> drivers/net/ethernet/8390/zorro8390.c
[...]
> Most of these are normal short-lived interrupts that only transfer
> a few bytes or schedule deferred processing of some sort.
> Most of the scsi and network drivers process the data in
> a softirq, so those are generally fine here, but I do see that 8390
> (ne2000) ethernet and the drivers/ide drivers do transfer their
> data in hardirq context.
>
>          Arnd

8390 ethernet drivers are widely used on m68k platforms (Amiga and 
Atari). At least on Amiga, the corresponding interrupt is a hardirq so 
I'd advise caution. That said, the 8390 drivers might benefit from some 
refactoring (the way these drivers are compiled does prevent e.g. the 
APNE driver from being used with two different variants of PCMCIA 
interfaces. I had begun some work on making IO primitives runtime 
selected two years ago but that ended up looking too ugly ...).

Can't recall what IPL the 8390 interrupts operate at - Geert?

Regarding allowing preemption of hardirqs - at least in 2017, that was 
considered perfectly OK (see Linus' comment on 
https://lore.kernel.org/patchwork/patch/794954/). I concur with Finn on 
this one - we did look for potential issues with the way irqs_disabled() 
is defined on m68k (for me, in the context of the above bug that caused 
memory corruption on my system), and found none.

Cheers,

    Michael