linux-kernel - Re: [PATCH] x86_64 irq: keep consistent for changing IRQ0

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]

Message-ID: <m1irdcdir5.fsf@ebiederm.dsl.xmission.com>
Date:	Wed, 07 Mar 2007 11:13:34 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Yinghai Lu <yinghai.lu@....com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Andi Kleen <ak@...e.de>
Subject: Re: [PATCH] x86_64 irq: keep consistent for changing IRQ0_VECTOR from 0x20 to 0x30

Linus Torvalds <torvalds@...ux-foundation.org> writes:

> On Mon, 5 Mar 2007, Yinghai Lu wrote:
>>
>> please check the patch
>
> Hmm.. It doesn't look *wrong*, but could you please
>
>  - split it up a bit (some of it is 100% obvious, ie the comment fixes)
>
>  - write an explanation for the individually split up patches
>
>  - not use attachments, but just make it inline. It's practically 
>    impossible to reply and quote part of the patch now.
>
> Eric/Ingo - did you go through and check the patch?

This patch will probably work but I'm against it, as is.

The comment fixes or some variation on them are needed.

But code that assumes we place IRQ0 at a particular place isn't
exactly bad but it is brittle.  If we are to reduce our array size
we can also shave a lot of entries off the top because we mostly use
the high end of the vector range for IPI's.

So if we were to introduce some set of defines of exactly which
vectors we can use and do a thorough job of this I think there may
be something reasonable we can do here.

Unless this makes the code clearer I don't think there is much point
in reducing a fixed sized array from 224 entries to 191 entries, and
it has the potential to make this much less pleasant if we goof up
elsewhere.

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/