linux-kernel - Re: oops in ioapic_write

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: <m18w4onebi.fsf@fess.ebiederm.org>
Date:	Tue, 03 Aug 2010 04:08:49 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Dave Airlie <airlied@...il.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: oops in ioapic_write_entry

Yinghai Lu <yinghai@...nel.org> writes:

> On 08/03/2010 02:15 AM, Eric W. Biederman wrote:
>> Yinghai Lu <yinghai@...nel.org> writes:
>> 
>> 
>> You can't share an edge triggered ISA irq, it isn't really physically
>> possible.  So I don't see how this extra complexity will change anything.
>> 

>
> Dave's system mptble:

Interesting he has ISA irqs on bus #10 on the same apic id and pin as
pci irqs.  Blink.  I had missed we had that print out.

The immediate issue are these lines:
> Int: type 0, pol 0, trig 0, bus 03, IRQ 00, APIC ID 0, APIC INT 10
> Int: type 0, pol 0, trig 0, bus 04, IRQ 00, APIC ID 0, APIC INT 10
> Int: type 0, pol 0, trig 0, bus 04, IRQ 01, APIC ID 0, APIC INT 11

Which get the apic id wrong, and thus cause us to mishandle them and
get 

You are right Dave's mptable does the  arguably broken:

> Int: type 0, pol 0, trig 0, bus 00, IRQ 28, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 00, IRQ 34, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 01, IRQ 02, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 05, IRQ 01, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 06, IRQ 00, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 07, IRQ 0c, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 07, IRQ 12, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 07, IRQ 15, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 07, IRQ 28, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 08, IRQ 01, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 09, IRQ 02, APIC ID 8, APIC INT 09
> Int: type 0, pol 0, trig 0, bus 0a, IRQ 09, APIC ID 8, APIC INT 09

Where busses 0,1,5,6,7,8,9 result in level triggered interrupts and
bus 0x0a results in an edge triggered interrupt.

As I read the code.  First we will do a generic isa setup, marking the
interrupt ioapic table entry edge triggered.  Then we will do a pci
setup for any pin we use as pci, and then we will set pin_programmed
stopping us from updating the pin any more, during setup.

For the common case I think we still do the right thing, even now, for
these broken bios tables.  There is likely an uncommon case for which
something like your shared_legacy_irq deserves to be used, especially
at it preserves our well tested historical behavior.

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/