linux-kernel - Re: [PATCH] i386 IOAPIC: de-fang IRQ compression

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, 04 Dec 2007 11:46:36 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Len Brown <lenb@...nel.org>,
	Natalie Protasevich <protasnb@...il.com>,
	Andi Kleen <ak@...e.de>, Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] i386 IOAPIC: de-fang IRQ compression

Ingo Molnar <mingo@...e.hu> writes:

> * Len Brown <lenb@...nel.org> wrote:
>
>>     So while the irq compression code on i386 should really
>>     be deleted -- even before merging the x86_64 irq-overhaul,
>>     this patch simply disables it on all high volume systems
>>     to avoid problems #1 and #2 on most all i386 systems.
>>     
>>     A large system with pin numbers >=64 will still have compression
>>     to conserve limited IRQ numbers for sparse IOAPICS.  However,
>>     the vast majority of the planet, those with only pin numbers < 64
>>     will use an identity GSI -> IRQ mapping.
>>     
>>     Signed-off-by: Len Brown <len.brown@...el.com>
>
> thanks for the patch and the extensive description. I've applied this to 
> x86.git. Do you agree that this has no urgency for v2.6.24 and is thus 
> v2.6.25 material?
>
> would you be interested in doing a follow-up patch as well that just 
> yanks all of the irq compression code? That would keep things nicely 
> bisectable and testable - the second, larger patch would be a NOP in 
> theory on most systems.

With respect to a follow on patch that removes irq compression.
We must raise NR_IRQs.

I have seen systems with > 256 GSIs (in the 4k ballpark) that
people occasionally boot 32bit kernels on.

However those systems seemed to use fewer then 200 or so of those irqs.
So as long as we are allocating vectors to irqs on demand (i.e. when
we find that the irq is hooked up or later) we should be ok.

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/