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:	Mon, 4 Jul 2011 15:10:17 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jan Beulich <JBeulich@...ell.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 5/6] x86: Remove useless unwinder backlink from irq regs
 saving

On Mon, Jul 04, 2011 at 11:17:42AM +0200, Ingo Molnar wrote:
> 
> * Jan Beulich <JBeulich@...ell.com> wrote:
> 
> > >>> On 02.07.11 at 18:29, Frederic Weisbecker <fweisbec@...il.com> wrote:
> > > The unwinder backlink in interrupt entry is very useless.
> > > It's actually not part of the stack frame chain and thus is
> > > never used.
> > 
> > I very much doubt this - see dump_trace()'s comment in its IRQ-stack
> > related code portion (and the corresponding use of irq_stack_end[-1]).
> 
> > > +++ b/arch/x86/kernel/entry_64.S
> > > @@ -327,7 +327,6 @@ ENDPROC(native_usergs_sysret64)
> > >  	jne 2f
> > >  	mov PER_CPU_VAR(irq_stack_ptr),%rsp
> > >  	EMPTY_FRAME 0
> > > -	pushq_cfi %rbp			/* backlink for unwinder */
> > >  	/*
> > >  	 * We entered an interrupt context - irqs are off:
> > >  	 */
> 
> Frederic, please add it back with a much better comment in the .S 
> showing where it's used and how. Perhaps even try to trigger the 
> usage of this backlink and document the effect in the changelog.

Ok. Please also consider the point Jan made: save_regs() was created
a while ago to convert code from a macro to a function in order to
reduce the amount of duplicated code amongst interrupts.

I did not think about that. On the other hand, keeping that into a
function unoptimize a bit the interrupt entries I think (but then
at the cost of increasing a bit the i-cache footprint?)

Not sure what we should do. We can still revert/zap the whole
and focus on pure stacktrace fixes without underlying optimizations.
--
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