linux-kernel - Re: PCI, ACPI, IRQ, IOAPIC: reroute PCI interrupt to legacy boot interrupt equivalent

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]

Message-ID: <m1prirx3xn.fsf@frodo.ebiederm.org>
Date:	Mon, 12 Jan 2009 19:47:32 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jon Masters <jcm@...hat.com>, Bjorn Helgaas <bjorn.helgaas@...com>,
	Stefan Assmann <sassmann@...e.de>, Len Brown <lenb@...nel.org>,
	Jesse Barnes <jbarnes@...tuousgeek.org>,
	Olaf Dabrunz <od@...e.de>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-acpi@...r.kernel.org, Sven Dietrich <sdietrich@...ell.com>,
	"Maciej W. Rozycki" <macro@...ux-mips.org>
Subject: Re: PCI, ACPI, IRQ, IOAPIC: reroute PCI interrupt to legacy boot interrupt equivalent

Ingo Molnar <mingo@...e.hu> writes:

> * Jon Masters <jcm@...hat.com> wrote:
>
>> On Mon, 2009-01-12 at 15:36 -0800, Eric W. Biederman wrote:
>> 
>> > This hardware behavior is not specific to boot interrupts or Intel.
>> 
>> It's not specific to Intel, but it is a specific compatibility behavior.
>> 
>> > Is this case really so interesting and compelling that we want to 
>> > fight through and figure what we need to do to make this work reliably 
>> > on every x86 chipset?
>> 
>> How else do you propose implementing IRQ handling in e.g. the RT kernel? 
>> We get a hardware interrupt, we can't FastEOI, we can't process 
>> synchronously, we can't do all of those things you might expect. 
>> Implementing RT requires that we delay handling of the IRQ until 
>> arbitrarily later in the future when we get around to it.
>
> a number of mainline drivers also mask/unmask irqs from within the IRQ 
> handler. It's not particularly smart in a native driver, but can happen - 
> and if we get an active line after that point (and this can happen because 
> the driver is active), we are in trouble.

Yep.  Right now it might be simpler to fix the mainline drivers.

If we can sit down and write some nice clean obviously correct patches
I am all for fixing this bug, possibly even a chipset at a time.

However this is a really weird case and people seem to be really struggling
to understand what is going on and to write those patches.  We are outside
the descriptions provided by ACPI so it requires chipset specific knowledge,
and a general understanding of how chipsets work to actually even comprehend
the problem.

Eric
--
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/