linux-kernel - Re: kernel BUG at arch/x86/kernel/io_apic

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:	Tue, 29 Jul 2008 18:29:02 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	"Yinghai Lu" <yhlu.kernel@...il.com>,
	"Mike Travis" <travis@....com>,
	"Dhaval Giani" <dhaval@...ux.vnet.ibm.com>,
	"Thomas Gleixner" <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...e.hu>, lkml <linux-kernel@...r.kernel.org>,
	"Jack Steiner" <steiner@....com>, "Alan Mayer" <ajm@....com>,
	"Cliff Wickman" <cpw@....com>
Subject: Re: kernel BUG at arch/x86/kernel/io_apic_64.c:357!

Alan Cox <alan@...rguk.ukuu.org.uk> writes:

> On Tue, 29 Jul 2008 16:12:50 -0700
> ebiederm@...ssion.com (Eric W. Biederman) wrote:
>
>> "Yinghai Lu" <yhlu.kernel@...il.com> writes:
>> 
>> >> But this would be a show stopper for SGI being able to ship systems if the
>> >> distros do not want to waste this much memory and won't set NR_CPUS=4096.
>> >
>> > wonder if nr_irqs need to be probed dynamically too.
>> 
>> NR_IRQS simply needs to die.
>
> Agreed - it would also be nice to bite the bullet at the same time and
> stop using dev->irq as an integer in an increasingly fake and imaginary
> numberspace and instead make it an object with a description and other
> properties. That would make "no IRQ" NULL, let us display meaningful IRQ
> strings and the like as well as ensuring nobody tries to abuse NR_IRQ and
> hardcoded similar knowledge for arrays

Unfortunately that is extremely expensive and hard.  Plus with NR_IRQs
going away the irq number space becomes sparse enough that the irq
numbers can become stable between boots, and as meaningful as they
have ever been.  At least for userspace an irq number is part of the
ABI so we will need one for the forseeable future.

We really need to change architecture specific code/generic irq code
first, preserving the number based interface to the drivers.  Then if
it looks useful change the drivers.

I would like nothing better then to change fields from "int irq" to
"struct irq_desc *irq" but unless we want to do a 2.7 we need a migration
path.  So we can change drivers slowly.  Which means providing both
interfaces in parallel for a while.

So it makes most sense to me to change everything beneath interfaces still
taking irq numbers (because that is where we get the performance and the
scalability improvements).  Then push forward with driver level changes.

Eric

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