linux-kernel - Re: 2.6.19-rc1 genirq causes either boot hang or "do

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:	Fri, 6 Oct 2006 09:02:54 -0700 (PDT)
From:	Linus Torvalds <torvalds@...l.org>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
cc:	Muli Ben-Yehuda <muli@...ibm.com>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Rajesh Shah <rajesh.shah@...el.com>, Andi Kleen <ak@....de>,
	"Protasevich, Natalie" <Natalie.Protasevich@...SYS.com>,
	"Luck, Tony" <tony.luck@...el.com>, Andrew Morton <akpm@...l.org>,
	Linux-Kernel <linux-kernel@...r.kernel.org>,
	Badari Pulavarty <pbadari@...il.com>
Subject: Re: 2.6.19-rc1 genirq causes either boot hang or "do_IRQ: cannot
 handle IRQ -1"

On Fri, 6 Oct 2006, Eric W. Biederman wrote:
> 
> The change the patch introduced was that we are now always
> pointing irqs towards individual cpus, and not accepting an irq
> if it comes into the wrong cpu.  

I think we should just revert that thing. I don't think there is any real 
reason to force irq's to specific cpu's: the vectors haven't been _that_ 
problematic a resource, and being limited to just 200+ possible vectors 
globally really hasn't been a real problem once we started giving out the 
vectors more sanely.

And the new code clearly causes problems, and it seems to limit our use of 
irq's in fairly arbitrary ways. It also would seem to depend on the irq 
routing being both sane and reliable, something I'm not sure we should 
rely on.

Also, I suspect the whole notion of only accepting an irq on one 
particular CPU is fundamentally fragile. The irq delivery tends to be a 
multi-phase process that we can't even _control_ from software (ie the irq 
may be pending inside an APIC or a bridge chip or other system logic, so 
things may be happening _while_ we possibly try to change the cpu 
delivery).

So how about just reverting that change?

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