[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a8595ec5-88db-072c-9cc3-7a3a301fe191@gmail.com>
Date: Fri, 19 Feb 2021 11:11:20 +1300
From: Michael Schmitz <schmitzmic@...il.com>
To: Arnd Bergmann <arnd@...nel.org>,
Finn Thain <fthain@...egraphics.com.au>
Cc: "Song Bao Hua (Barry Song)" <song.bao.hua@...ilicon.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
"arnd@...db.de" <arnd@...db.de>,
"geert@...ux-m68k.org" <geert@...ux-m68k.org>,
"funaho@...ai.org" <funaho@...ai.org>,
"philb@....org" <philb@....org>, "corbet@....net" <corbet@....net>,
"mingo@...hat.com" <mingo@...hat.com>,
"linux-m68k@...ts.linux-m68k.org" <linux-m68k@...ts.linux-m68k.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC] IRQ handlers run with some high-priority interrupts(not
NMI) enabled on some platform
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
Powered by blists - more mailing lists