linux-kernel - [PATCH] Use delayed disable mode of ioapic edge triggered interrupts

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: <m18xidlxv7.fsf_-_@ebiederm.dsl.xmission.com>
Date:	Tue, 14 Nov 2006 10:52:12 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Ingo Molnar <mingo@...hat.com>, Komuro <komurojun-mbn@...ty.com>,
	tglx@...utronix.de, Adrian Bunk <bunk@...sta.de>,
	Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: [PATCH] Use delayed disable mode of ioapic edge triggered interrupts


Linus Torvalds <torvalds@...l.org> writes:

> Of course, for edge-triggered APIC interrupts, we _have_ to replay the irq 
> (since we don't have any way of even *knowing* whether we might get it 
> again), but for level-triggered and for the old legacy i8259 controller 
> that gets it right for edges anwyay, we should _not_ send the spurious 
> interrupt that is no longer active.
>
> And a lot of code has been tested with either just the i8259 (old machines 
> without any APIC) or with PCI-only devices (which are always level- 
> triggered), so the fact that edge-triggered things have always seen the 
> potential for spurious interrupts is not a reasong to say "well, they have 
> to handle it anyway". True PCI drivers generally do _not_ have to handle 
> the crazy case, and generally have never seen it.
>
> In other words, I think we should just make APIC-edge have the "please 
> delay masking and replay" bit, and nobody else.
>
> Can you send that patch (for both x86 and x86-64), and we can ask Komuro 
> to test it. That would be the "same behaviour as we've always had" thing, 
> which I think is also the _right_ behaviour.

Hopefully this is the trivial patch that solves the problem.

Signed-off-by: Eric W. Biederman <ebiederm@...ssion.com>

diff --git a/arch/i386/kernel/io_apic.c b/arch/i386/kernel/io_apic.c
index ad84bc2..3b7a63e 100644
--- a/arch/i386/kernel/io_apic.c
+++ b/arch/i386/kernel/io_apic.c
@@ -1287,9 +1287,11 @@ static void ioapic_register_intr(int irq
 			trigger == IOAPIC_LEVEL)
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					 handle_fasteoi_irq, "fasteoi");
-	else
+	else {
+		irq_desc[irq].status |= IRQ_DELAYED_DISABLE;
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					 handle_edge_irq, "edge");
+	}
 	set_intr_gate(vector, interrupt[irq]);
 }
 
diff --git a/arch/x86_64/kernel/io_apic.c b/arch/x86_64/kernel/io_apic.c
index 41bfc49..14654e6 100644
--- a/arch/x86_64/kernel/io_apic.c
+++ b/arch/x86_64/kernel/io_apic.c
@@ -790,9 +790,11 @@ static void ioapic_register_intr(int irq
 			trigger == IOAPIC_LEVEL)
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					      handle_fasteoi_irq, "fasteoi");
-	else
+	else {
+		irq_desc[irq].status |= IRQ_DELAYED_DISABLE;
 		set_irq_chip_and_handler_name(irq, &ioapic_chip,
 					      handle_edge_irq, "edge");
+	}
 }
 
 static void __init setup_IO_APIC_irqs(void)

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