Re: lockdep and threaded IRQs (was: ...)

[Ingo Molnar <mingo@elte.hu>]

* Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> > Hm, that reads like the boot IRQ erratas of certain chipsets 
> > - the APIC could throw a fit essentially locking up the 
> > system. FYI, we have fixes for that upstream already.
> 
> Good - certainly it used to be the case that masking APIC IRQs 
> and leaving them masked from the IRQ handled used to do funny 
> things sometimes.

I think being careful is definitely warranted in the case of 
IDE. I'd not be surprised if not all chipsets are mapped via the 
boot-IRQ quirks: those quirks are opt-in based on PCI IDs - 
those tend to be the quirk mechanisms with the least coverage. 
(The IDs were also derived from enterprise testing of -rt, which 
tends to under-emphasise cheap broken chipsets.)

Plus the erratum you described about doing an IRQ masking 
mid-PIO-transfer confusing the chipset can also be a separate 
standalone bug not permitting an irq-masking based IRQ flow at 
all on such hardware.

So your worries are spot on IMO and are not being dismissed 
forcibly.

> > i think you severely over-estimate the importance and ratio 
> > of drivers that enable irqs within irq handlers. (Nor does 
> > anyone want to break them really - we want to have a sane 
> > default and we want to flag the broken cases as broken.)
> 
> IDE. A lot less people use the IDE stack nowdays but its a big 
> item and getting it wrong tends to eat your files.
> 
> I do object to the attitude shown about "forcing" people. It's 
> a community project built by a large number of people on a mix 
> of pragmatic and elegant design balances. Maybe it's just 
> unfortunate choice of wording but it is the wrong sentiment.

It was in the heat of the argument i think ...

(I do think we need to be somewhat less permissive in terms of 
weird driver practices, but that's just my opinion and not 
'enforced' via any artificial way.)

	Ingo