linux-kernel - Re: [v3.4-rc1] ACPI regression bisected

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:	Wed, 18 Apr 2012 12:29:32 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Paul Bolle <pebolle@...cali.nl>
cc:	Andi Kleen <ak@...ux.intel.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	Jörg Otte <jrg.otte@...glemail.com>,
	LKML <linux-kernel@...r.kernel.org>, Len Brown <lenb@...nel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>
Subject: Re: [v3.4-rc1] ACPI regression bisected

B1;2601;0cOn Wed, 18 Apr 2012, Paul Bolle wrote:
> On Thu, 2012-04-12 at 22:42 +0200, Thomas Gleixner wrote:
> > > For 3.4 I think reverting is the right approach.
> > 
> > Ack.
> 
> A revert of 6fe0d0628245fdcd6fad8b837c81e8f7ebc3364d ("ACPI: Make ACPI
> interrupt threaded") wasn't included in v3.4-rc3. Has it been pushed
> somewhere? Is testing needed before that revert can be pushed?

Seems those who broke it are too busy to care.

Linus, can you please apply directly?

------------>
Subject: ACPI: Revert 6fe0d06 ("ACPI: Make ACPI interrupt threaded")
From: Thomas Gleixner <tglx@...utronix.de>

Paul bisected this regression to 6fe0d06 ("ACPI: Make ACPI interrupt
threaded"). 

The conversion was done blindly and is wrong, as it does not provide a
primary handler to disable the level type irq on the device
level. Neither does it set the IRQF_ONESHOT flag which handles that at
the irq line level. This can't be done as the interrupt might be
shared, though we might extend the core to force it.

So an interrupt on this line will wake up the thread, but immediately
unmask the irq after that. Due to the interrupt being level type the
hardware interrupt is raised over and over and prevents the irq thread
from handling it. Fail.

request_irq() unfortunately does not refuse such a request and the
patch was obviously never tested with real interrupts.

Bisected-by: Paul Bolle <pebolle@...cali.nl>
Signed-off-by: Thomas Gleixner <tglx@...utronix.de>

diff --git b/drivers/acpi/osl.c a/drivers/acpi/osl.c
index 02367a8..412a1e0 100644
--- b/drivers/acpi/osl.c
+++ a/drivers/acpi/osl.c
@@ -595,8 +595,7 @@ acpi_os_install_interrupt_handler(u32 gsi, acpi_osd_handler handler,

 	acpi_irq_handler = handler;
 	acpi_irq_context = context;
-	if (request_threaded_irq(irq, NULL, acpi_irq, IRQF_SHARED, "acpi",
-				 acpi_irq)) {
+	if (request_irq(irq, acpi_irq, IRQF_SHARED, "acpi", acpi_irq)) {
 		printk(KERN_ERR PREFIX "SCI (IRQ%d) allocation failed\n", irq);
 		acpi_irq_handler = NULL;
 		return AE_NOT_ACQUIRED;

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