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:	Wed, 19 Nov 2008 09:54:23 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Alexander van Heukelum <heukelum@...lshack.com>
CC:	LKML <linux-kernel@...r.kernel.org>,
	Andi Kleen <andi@...stfloor.org>,
	Jan Beulich <jbeulich@...ell.com>, Ingo Molnar <mingo@...e.hu>,
	Glauber Costa <gcosta@...hat.com>,
	Matt Mackall <mpm@...enic.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	Cyrill Gorcunov <gorcunov@...il.com>
Subject: Re: [PATCH/RFC] Move entry_64.S register saving out of the macros

Alexander van Heukelum wrote:
> Hi all,
> 
> Here is a combined patch that moves "save_args" out-of-line for
> the interrupt macro and moves "error_entry" mostly out-of-line
> for the zeroentry and errorentry macros.
> 
> The save_args function becomes really straightforward and easy
> to understand, with the possible exception of the stack switch
> code, which now needs to copy the return address of to the
> calling function. Normal interrupts arrive with ((~vector)-0x80)
> on the stack, which gets adjusted in common_interrupt:
> 
> <common_interrupt>:
> (5)  addq   $0xffffffffffffff80,(%rsp)		/* -> ~(vector) */
> (4)  sub    $0x50,%rsp				/* space for registers */
> (5)  callq  ffffffff80211290 <save_args>
> (5)  callq  ffffffff80214290 <do_IRQ>
> <ret_from_intr>:
>      ...
> 
> An apic interrupt stub now look like this:
> 
> <thermal_interrupt>:
> (5)  pushq  $0xffffffffffffff05			/* ~(vector) */
> (4)  sub    $0x50,%rsp				/* space for registers */
> (5)  callq  ffffffff80211290 <save_args>
> (5)  callq  ffffffff80212b8f <smp_thermal_interrupt>
> (5)  jmpq   ffffffff80211f93 <ret_from_intr>
> 

Sorry, I'm away on a trip at the moment, so sorry for the delayed feedback.

First of all, if we're going to go through common code here, we should 
do the vector number adjustment in save_args and be able to use the 
short form of pushq in the common case.

What isn't clear to me is if we should just push a target field to the 
stack and then do an indirect call.  That way we can do save_args and 
ret_from_intr inline, but at the expense of an indirect call which will 
not necessarily speculate cleanly.

All of this qualify as "tweaking", which means we need to be very 
careful so we don't end up burning more performance than we gain, but 
all in all, I think this is a good idea.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ