linux-kernel - Re: [patch 3/3] genirq: mark io_apic level interrupts to avoid resend

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, 13 Aug 2007 13:28:21 +0200
From:	Jarek Poplawski <jarkao2@...pl>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Stable Team <stable@...nel.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Jean-Baptiste Vignaud <vignaud@...dmail.fr>,
	"marcin\.slusarz" <marcin.slusarz@...il.com>
Subject: Re: [patch 3/3] genirq: mark io_apic level interrupts to avoid resend

On Sun, Aug 12, 2007 at 03:46:36PM -0000, Thomas Gleixner wrote:
> Level type interrupts do not need to be resent. It was also found that
> some chipsets get confused in case of the resend. 

IMHO, it's still not proven the chipsets are to blame here
(plus read below).

> 
> Mark the ioapic level type interrupts as such to avoid the resend
> functionality in the generic irq code.
> 
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> 
> ---
>  arch/i386/kernel/io_apic.c   |    7 +++++--
>  arch/x86_64/kernel/io_apic.c |    7 +++++--
>  2 files changed, 10 insertions(+), 4 deletions(-)
> 
> Index: linux-2.6/arch/i386/kernel/io_apic.c
> ===================================================================
> --- linux-2.6.orig/arch/i386/kernel/io_apic.c	2007-08-11 11:09:11.000000000 +0200
> +++ linux-2.6/arch/i386/kernel/io_apic.c	2007-08-11 11:09:12.000000000 +0200
> @@ -1256,12 +1256,15 @@ static struct irq_chip ioapic_chip;
>  static void ioapic_register_intr(int irq, int vector, unsigned long trigger)
>  {
>  	if ((trigger == IOAPIC_AUTO && IO_APIC_irq_trigger(irq)) ||
> -			trigger == IOAPIC_LEVEL)
> +	    trigger == IOAPIC_LEVEL) {
> +		irq_desc[irq].status |= IRQ_LEVEL;
>  		set_irq_chip_and_handler_name(irq, &ioapic_chip,
>  					 handle_fasteoi_irq, "fasteoi");
> -	else
> +	} else {
> +		irq_desc[irq].status &= ~IRQ_LEVEL;
>  		set_irq_chip_and_handler_name(irq, &ioapic_chip,
>  					 handle_edge_irq, "edge");
> +	}
>  	set_intr_gate(vector, interrupt[irq]);
>  }
>  
> Index: linux-2.6/arch/x86_64/kernel/io_apic.c
> ===================================================================
> --- linux-2.6.orig/arch/x86_64/kernel/io_apic.c	2007-08-11 11:09:11.000000000 +0200
> +++ linux-2.6/arch/x86_64/kernel/io_apic.c	2007-08-11 11:09:12.000000000 +0200
> @@ -800,12 +800,15 @@ static struct irq_chip ioapic_chip;
>  
>  static void ioapic_register_intr(int irq, unsigned long trigger)
>  {
> -	if (trigger)
> +	if (trigger) {
> +		irq_desc[irq].status |= IRQ_LEVEL;
>  		set_irq_chip_and_handler_name(irq, &ioapic_chip,
>  					      handle_fasteoi_irq, "fasteoi");
> -	else
> +	} else {
> +		irq_desc[irq].status &= ~IRQ_LEVEL;
>  		set_irq_chip_and_handler_name(irq, &ioapic_chip,
>  					      handle_edge_irq, "edge");
> +	}
>  }
>  
>  static void setup_IO_APIC_irq(int apic, int pin, unsigned int irq,
> 
> -- 
> 

Maybe I miss something, but:
- why it's not done in other places with handle_level_irq or
handle_fasteoi_irq. Are we sure they can never get IRQ_PENDING flag
or we take the risk?
- what about e.g. handle_simple_irq: do we think it needs resending
or simply going to wait for good bug reports?
- is this .status cleared enough on free_irq or during request_irq?

BTW, of course something like this set of patches was needed here,
but I still think this shouldn't be done this way: the bug wasn't
diagnosed nor tested enough, some chips are suspected, and
nevertheless the change is done for everybody, whithout any
possibility to set this back for people who had no problems with
2.6.21 and 2.6.22 (at least for some transition time). Maybe some
other chips get confused now, and we get some notice of this maybe
only in 2.6.25, if we'are lucky enough to have somebody like Marcin
around to do the next git bisection?

Regards,
Jarek P.
-
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/