Re: [PATCH] Prevent nested interrupts when the IRQ stack is near overflowing v2

[Alan Cox <alan@lxorguk.ukuu.org.uk>]

> Which leads to the general question why we have that IRQF_DISABLED
> shite at all. AFAICT the historical reason were IDE drivers, but we
> grew other abusers like USB, SCSI and other crap which runs hard irq
> handlers for hundreds of micro seconds in the worst case.

Anyone you've forgotten to offend ?

We have IRQF_DISABLED and stuff using that model because for something
like ten years the Linux kernel had no real sane notion of handing stuff
off to worker threads or threaded irq support and also because there were
so many errata around IRQ masking as well as all the evil business
with interrupt delivery being asynchronous to the PCI or ISA transactions
on some CPUs (eg you could write the irq mask register on the device,
read it back to ensure it occurred and *still* get an IRQ delivered after
that point because it was on the APIC bus)

Dumping everyones code under an insult without any historical context
isn't helpful.

Pretty much the only 'core' driver today which enables IRQs in the irq
handlers and needs it is the old IDE layer. There are also a couple of
drivers which play games with disable/enable_irq in the IRQ paths for
other reasons (lack of irq threads when written and a hardware model thats
totally SMP unfriendly). 8390 is the obvious one here and it at least
would be far far saner using threaded IRQs and normal locking with IRQs
unmasked.

Alan