linux-kernel - Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for some HP systems

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:	Mon, 7 Jul 2008 21:10:56 +0100 (BST)
From:	"Maciej W. Rozycki" <macro@...ux-mips.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
cc:	Ingo Molnar <mingo@...e.hu>, Matthew Garrett <mjg59@...f.ucam.org>,
	Len Brown <lenb@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-next@...r.kernel.org, linux-acpi@...r.kernel.org,
	linux-kernel@...r.kernel.org, Andi Kleen <andi@...stfloor.org>
Subject: Re: [PATCH 2/2] acpi: Disable IRQ 0 through I/O APIC for some HP
 systems

On Mon, 7 Jul 2008, Rafael J. Wysocki wrote:

> Sorry, the patch I posted was _instead_ of your previous patch with the quirk,
> because that patch didn't work.  I don't know why it didn't work, however, I
> can only say it didn't work after removing the __i386__ dependency of
> acpi_dmi_table[].

 I don't recall seeing a note that my patch was reverted.  I had a careful
look at yours now and it applies on top of some diagnostic code which
should never have been applied to the tree in the first place as it was
not meant to and would also break the majority of systems out there.  I am
fairly sure this piece of code is the reason my implementation of the
workaround did not work for you.

> My patch is on top of the linux-next tree that didn't contain your patch.
> So, my patch adds a quirk that sets disable_irq0_through_ioapic to 1 (this
> variable is defined differently in my patch) and uses it to skip the part of
> check_timer() that breaks my box.
> 
> I hope that makes things clear.

 It does, thanks.  However I insist on getting this issue dealt with the
way I proposed -- check_timer() is too complicated and too fragile to mess
with as our history has already shown.  If IRQ0 is not to be routed
through the I/O APIC, then it should never be registered as an I/O APIC
interrupt in the first place.

 I am fairly with the offending change removed my fix will work for you as
expected as I went through the effort of checking at the run time that
once activated it makes the kernel correctly avoid the sequence in
check_timer() that hits your system, so it is only the DMI ID matching
that could have gone wrong, but your change indicates this is actually not
the case.

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