Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753389AbbGUIAv (ORCPT ); Tue, 21 Jul 2015 04:00:51 -0400 Received: from mail-wi0-f179.google.com ([209.85.212.179]:32783 "EHLO mail-wi0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753285AbbGUIAW (ORCPT ); Tue, 21 Jul 2015 04:00:22 -0400 Date: Tue, 21 Jul 2015 10:00:16 +0200 From: Ingo Molnar To: Josh Poimboeuf Cc: Andy Lutomirski , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Michal Marek , Peter Zijlstra , Andy Lutomirski , Borislav Petkov , Linus Torvalds , Andi Kleen , Pedro Alves , X86 ML , live-patching@vger.kernel.org, "linux-kernel@vger.kernel.org" Subject: Re: [RFC PATCH 13/21] x86/asm/crypto: Fix frame pointer usage in aesni-intel_asm.S Message-ID: <20150721080016.GA26811@gmail.com> References: <2ea0f0602978178eafd012e52b8bdb83cfb159d5.1437150175.git.jpoimboe@redhat.com> <20150717194307.GA26757@gmail.com> <20150717203746.GB12761@treble.redhat.com> <20150718025116.GB13059@gmail.com> <20150718035623.GA22664@treble.redhat.com> <20150720163646.GA28075@treble.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150720163646.GA28075@treble.redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2761 Lines: 62 * Josh Poimboeuf wrote: > On Mon, Jul 20, 2015 at 08:30:52AM -0700, Andy Lutomirski wrote: > > On Fri, Jul 17, 2015 at 8:56 PM, Josh Poimboeuf wrote: > > > The reason I suggested to put FRAME in the macro name is to try to > > > prevent it from being accidentally used for leaf functions, where it > > > isn't needed. > > > > > > > Could someone remind me why it isn't needed for leaf functions? > > If a function doesn't call any other functions, then it won't ever show > up in a stack trace unless: > > a) the function itself walks the stack, in which case the frame pointer > isn't necessary; or > > b) The function gets hit by an interrupt/exception, in which case frame > pointers can't be 100% relied upon anyway. > > I've noticed that gcc *does* seem to create stack frames for leaf functions. > But it's inconsistent, because the early exit path of some functions will skip > the stack frame creation and go straight to the return. > > We could probably get a good performance boost with the > -momit-leaf-frame-pointer flag. Though it would make stack traces less reliable > when a leaf function gets interrupted. So in theory we could resolve this during the stack walk: when we pass from the IRQ stack to the process stack we actually know the RIP of the interrupted context, and could include that. Visualizing context boundaries in the stack dump would also be pretty useful independently of the performance boost. We already demark them to a certain degree: [ 37.287036] Call Trace: [ 37.287042] [] dump_stack+0x4c/0x65 [ 37.287045] [] ? down_trylock+0x28/0x33 [ 37.287048] [] warn_slowpath_common+0x7b/0xb1 [ 37.287050] [] warn_slowpath_fmt+0x50/0x6e [ 37.287053] [] ? __do_softirq+0x224/0x289 [ 37.287055] [] ? __do_softirq+0x1b1/0x289 [ 37.287057] [] can_stop_full_tick+0x69/0xa1 [ 37.287059] [] tick_nohz_irq_exit+0x72/0x98 [ 37.287061] [] irq_exit+0xbf/0x104 [ 37.287064] [] smp_apic_timer_interrupt+0x42/0x51 [ 37.287067] [] apic_timer_interrupt+0x89/0x90 [ 37.287071] [] ? ___might_sleep+0x150/0x232 [ 37.287075] [] ? lock_torture_reader+0x102/0x102 including the RIP of interrupted nested contexts would be helpful. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/