linux-kernel - Re: [patch] genirq: do not mask interrupts by default

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20061115174604.GA24429@elte.hu>
Date:	Wed, 15 Nov 2006 18:46:04 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Linus Torvalds <torvalds@...l.org>
Cc:	Ingo Molnar <mingo@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.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: Re: [patch] genirq: do not mask interrupts by default


* Linus Torvalds <torvalds@...l.org> wrote:

> On Wed, 15 Nov 2006, Ingo Molnar wrote:
> > 
> > problem is, we dont know /for a fact/ that something is "APIC-edge". 
> > We only know that the BIOS claims it that it's so.
> 
> This is incorrect. We will have _programmed_ the APIC with whatever 
> the BIOS said in the MP tables, so if we think it's level triggered, 
> it _is_ level triggered.

yeah. I was thinking about the low 16 irqs (those are really the problem 
spots most of the time, not the normal IO-APIC irqs) - which are routed 
all across the southbridge and might end up being handled by a 
i8259A-lookalike entity. Right now we default to level-triggered IRQ 
flow handling:

                if (i < 16) {
                        /*
                         * 16 old-style INTA-cycle interrupts:
                         */
                        set_irq_chip_and_handler_name(i, &i8259A_chip,
                                                      handle_level_irq, "XT");

because that's the best we can do (it's also what our i8259 code did 
historically). But it would be one step safer to also do the 
lazy-disable. Just in case things might get lost while masked. Or is 
that an absolutely horrible hardware breakage that i shouldnt worry 
about?

> So I really think that all the arguments for i8259 not wanting replay 
> weigh equally on level-triggered PCI irq's too.
> 
> Now, the one thing that makes me think your approach is the right one 
> is that it's potentially going to be better performance - if people 
> disable irq's and the normal case is that no irq will actually happen, 
> then optimistically not doing anything at all (except marking the irq 
> disabled, of course) is always good.
> 
> However, because it's a semantic change, I _really_ don't want to do 
> it right now. We're maybe a week away from 2.6.19, and the "ISA irq's 
> don't work" report is one of the things that is holding things up 
> right now.
>
> So that's why I'd much rather go with Eric's patch for now - because 
> it keeps the semantics that we've always had.

ok, i'm fine with Eric's patch too, if it solves Komuro's problem:

  Acked-by: Ingo Molnar <mingo@...e.hu>

and we dont have to worry about the present ugliness of the 
delayed-disabled flag either, as it would just go away in 2.6.20.

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