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

Ingo Molnar
2009-03-03T11:34:11Z

* 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