linux-kernel - Re: lockdep and threaded IRQs (was: ...)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Mar 2009 12:33:13 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	David Brownell <david-b@...bell.net>,
	Andrew Morton <akpm@...ux-foundation.org>, me@...ipebalbi.com,
	linux-kernel@...r.kernel.org, linux-input@...r.kernel.org,
	felipe.balbi@...ia.com, dmitry.torokhov@...il.com,
	sameo@...nedhand.com, tglx@...utronix.de
Subject: Re: lockdep and threaded IRQs (was: ...)


* Alan Cox <alan@...rguk.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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/