linux-kernel - Re: Other problem/regression with b9c61b70075c87a8612624736faf4a2de5b1ed30

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, 23 Feb 2010 12:17:11 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Yinghai Lu <yinghai@...nel.org>
Cc:	Thomas Renninger <trenn@...e.de>, Gary Hade <garyhade@...ibm.com>,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Iranna D Ankad <iranna.ankad@...ibm.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Suresh Siddha <suresh.b.siddha@...el.com>, len.brown@...el.com,
	"linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Other problem/regression with b9c61b70075c87a8612624736faf4a2de5b1ed30

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

> On 02/23/2010 01:07 AM, Yinghai Lu wrote:
>> Gary,
>> 
>> can you check this patch on your x3950?
>
> Subject: [PATCH -v2] x86: fix out of order of gsi
>
> found IBM x3950 will have problem after
>
> |commit b9c61b70075c87a8612624736faf4a2de5b1ed30
> |
> |    x86/pci: update pirq_enable_irq() to setup io apic routing
>
> The problem is that with the patch, the machine freezes when
> console=ttyS0,... kernel serial parameter is passed.
> It seem to freeze at DVD initialization and the whole problem seem
> to be DVD/pata related, but somehow exposed through the serial
> parameter.
> Such apic problems can expose really weird behavior..
>
> <6>ACPI: IOAPIC (id[0x10] address[0xfecff000] gsi_base[0])
> <6>IOAPIC[0]: apic_id 16, version 0, address 0xfecff000, GSI 0-2
> <6>ACPI: IOAPIC (id[0x0f] address[0xfec00000] gsi_base[3])
> <6>IOAPIC[1]: apic_id 15, version 0, address 0xfec00000, GSI 3-38
> <6>ACPI: IOAPIC (id[0x0e] address[0xfec01000] gsi_base[39])
> <6>IOAPIC[2]: apic_id 14, version 0, address 0xfec01000, GSI 39-74
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 1 global_irq 4 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 5 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 3 global_irq 6 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 4 global_irq 7 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 6 global_irq 9 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 7 global_irq 10 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 8 global_irq 11 low edge)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 12 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 12 global_irq 15 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 13 global_irq 16 dfl dfl)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 14 global_irq 17 low edge)
> <6>ACPI: INT_SRC_OVR (bus 0 bus_irq 15 global_irq 18 dfl dfl)
>
> it turns out that system have three io apic controller. but put boot ioapic
> routing in second one. and that gsi_base is not 0. it is using bunch of INT_SRC_OVR...
>
> recent changes
> 1. one set routing for first io apic controller
> 2. assume irq = gsi
> will break theat system.
>
> so try to remap those gsi, need to seperate boot_ioapic_id detection out of enable_IO_APIC
> and call them early.
> introduce boot_ioapic_id, and remap_ioapic_gsi...
>
> -v2: shift gsi with delta instead of gsi_base of boot_ioapic_idx
>
> Reported-by: Iranna D Ankad <iranna.ankad@...ibm.com>
> Bisected-by: Iranna D Ankad <iranna.ankad@...ibm.com>
> Cc: Thomas Renninger <trenn@...e.de>
> Cc: stable@...nel.org
> Signed-off-by: Yinghai Lu <yinghai@...nel.org>

> +int remap_ioapic_gsi(int ioapic, u32 gsi)
> +{
> +	int base_boot = mp_gsi_routing[boot_ioapic_idx].gsi_base;
> +	int base_x;
> +
> +	if (!base_boot)
> +		return gsi;
> +
> +	base_x = mp_gsi_routing[ioapic].gsi_base;
> +	if (base_x < base_boot) {
> +		int delta;
> +		delta = mp_gsi_routing[boot_ioapic_idx].gsi_end + 1;
> +		delta -= base_boot;
> +		gsi += delta;
> +	} else if (base_x == base_boot)
> +		gsi -= base_boot;
> +
> +	return gsi;
> +}

This looks like it is doing something very different from implementing a
one irq at a time override, and after the nasties remapping gsi have
caused in the past I find this function very scary.

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/