linux-kernel - Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

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 Nov 2008 11:07:40 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alexander van Heukelum <heukelum@...tmail.fm>
CC:	Andi Kleen <andi@...stfloor.org>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Alexander van Heukelum <heukelum@...lshack.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>, lguest@...abs.org,
	jeremy@...source.com, Steven Rostedt <srostedt@...hat.com>,
	Mike Travis <travis@....com>
Subject: Re: [PATCH RFC/RFB] x86_64, i386: interrupt dispatch changes

Alexander van Heukelum wrote:
> 
> Thanks for the info!
> 
> This just means that if there are performance problems, the
> 'specialized'
> handlers should be using the kernel segment or maybe a single common
> segment. It would still allow us to get rid of the trampolines. A stack
> trace should be enough to reconstruct which vector was originally called
> in that case. Only the common_interrupt-codepath needs the original
> vector as far as I can see.
> 
> You just made testing on larger machines with a lot of external
> interrupts necessary :-/. (Assuming small machines do not show
> performance problems, that is.)
> 

Overall, it more than anything else show the x86 architectural
braindamage of not having an interrupt vector number register available
anywhere.  However, I suspect using segment registers is liable to
suffer from a "wall of jello" effect once you overflow the segment
descriptor cache, which will typically be around 32 entries in size.

Now, at least on my kernel, the existing IRQ stubs are rather weird:
they are padded to 8 bytes and then misaligned onto a 4-byte boundary.
Furthermore, at the cost of an extra jump, they can trivially be
compressed down to 4 bytes apiece instead of 7-padded-to-8.

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