On Thu, Feb 18, 2021 at 6:30 AM Finn Thain <fth...@telegraphics.com.au> wrote: > On Wed, 17 Feb 2021, Song Bao Hua (Barry Song) wrote: > > > On Sat, 13 Feb 2021, Song Bao Hua (Barry Song) wrote: > > > > > > That scenario seems a little contrived to me (drivers for two or more > > > devices sharing state through their interrupt handlers). Is it real? I > > > suppose every platform has its quirks. The irq lock in > > > sonic_interrupt() is only there because of a platform quirk (the same > > > device can trigger either of two IRQs). Anyway, no-one expects all > > > drivers to work on all platforms; I don't know why it bothers you so > > > much when platforms differ. > > > > Basically, we wrote drivers with the assumption that this driver will be > > cross-platform. (Of course there are some drivers which can only work on > > one platform, for example, if the IP of the device is only used in one > > platform as an internal component of a specific SoC.) > > > > So once a device has two or more interrupts, we need to consider one > > interrupt might preempt another one on m68k on the same cpu if we also > > want to support this driver on m68k. this usually doesn't matter on > > other platforms. > > When users show up who desire to run your drivers on their platform, you > can expect them to bring patches and a MAINTAINERS file entry. AFAIK, > Linux development has always worked that way.
This is only part of the picture though. We also also constantly trying to generalize the internal interfaces, to make sure that platforms work the same way and that it's possible to write drivers in a portable way without having to rely on platform maintainers to point out the differences. I think it would make a lot of sense to remove the architecture differences here by making m68k work the same way as the others and documenting that as the expected behavior. You are probably right that there are no specific bugs on m68k machines that rely on the nested hardirqs today, but I think they only get away with it because a) there is no SMP support on m68k, so it likely doesn't run into the more subtle cases with lock ordering that you could get when you have hardirq handlers on multiple CPUs in parallel b) there is a very limited number of device drivers that are actually used on m68k, in particular only M54xx has PCI support, but that in turn has a different interrupt scheme. Changing the behavior on m68k clearly has its own regression risk, but it could be done as a configuration option that defaults to the traditional behavior on machines that have not been verified to be well-behaved without nested hardirqs, and hidden on machines that do not need it (any more). As far as I can tell, the only reason you would actually need nested hardirqs is when a low-priority interrupt has to perform expensive I/O processing, but we've had countless other methods to do the same over the years (at least bottom half, softirq, taskqueue, tasklet, keventd, workqueue, kthread, threaded interrupt handlers and probably others). It would probably not be too hard to go through all drivers that are normally enabled and see if their interrupt handler should be changed to use deferred processing (threaded irq handler or workqueue) instead of doing expensive I/O in hardirq context and relying on priorities. FWIW, these are the drivers in m68k multi_defconfig that register an interrupt: $ find build/tmp/{drivers,sound} -name \*.o | xargs grep request_.*irq | cut -f 3- -d/ | cut -f 1 -d\ | sed -e "s:o$:c:g" drivers/block/amiflop.c drivers/ide/ide-probe.c drivers/input/joystick/amijoy.c drivers/input/keyboard/amikbd.c drivers/input/keyboard/hilkbd.c drivers/input/mouse/amimouse.c drivers/input/serio/hp_sdc.c drivers/input/serio/q40kbd.c drivers/macintosh/via-cuda.c drivers/macintosh/via-macii.c drivers/macintosh/via-pmu.c drivers/misc/dummy-irq.c 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 drivers/net/ethernet/amd/7990.c drivers/net/ethernet/amd/a2065.c drivers/net/ethernet/amd/ariadne.c drivers/net/ethernet/amd/atarilance.c drivers/net/ethernet/amd/sun3lance.c drivers/net/ethernet/apple/macmace.c drivers/net/ethernet/cirrus/mac89x0.c drivers/net/ethernet/i825xx/82596.c drivers/net/ethernet/natsemi/macsonic.c drivers/net/ethernet/smsc/smc91x.c drivers/net/phy/phy.c drivers/parport/parport_amiga.c drivers/parport/parport_atari.c drivers/parport/parport_mfc3.c drivers/parport/parport_pc.c drivers/scsi/a2091.c drivers/scsi/a3000.c drivers/scsi/a4000t.c drivers/scsi/atari_scsi.c drivers/scsi/bvme6000_scsi.c drivers/scsi/gvp11.c drivers/scsi/mac_esp.c drivers/scsi/mac_scsi.c drivers/scsi/mvme147.c drivers/scsi/mvme16x_scsi.c drivers/scsi/sun3x_esp.c drivers/scsi/zorro7xx.c drivers/scsi/zorro_esp.c drivers/tty/amiserial.c drivers/tty/serial/pmac_zilog.c drivers/video/fbdev/amifb.c drivers/video/fbdev/atafb.c sound/oss/dmasound/dmasound_atari.c sound/oss/dmasound/dmasound_paula.c sound/oss/dmasound/dmasound_q40.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