From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751524AbdCPJY0 (ORCPT ); Thu, 16 Mar 2017 05:24:26 -0400 Received: from mail.kernel.org ([198.145.29.136]:47040 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751037AbdCPJYY (ORCPT ); Thu, 16 Mar 2017 05:24:24 -0400 Date: Thu, 16 Mar 2017 18:24:12 +0900 From: Masami Hiramatsu To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Andrew Morton , Thomas Gleixner , Peter Zijlstra , Masami Hiramatsu , "H. Peter Anvin" , Andy Lutomirski , Josh Poimboeuf , Linus Torvalds Subject: Re: [RFC][PATCH 5/5] ftrace/x86-32: Add -mfentry support to x86_32 with DYNAMIC_FTRACE set Message-Id: <20170316182412.965a091f2721062b21556da7@kernel.org> In-Reply-To: <20170315200255.828608428@goodmis.org> References: <20170315195527.703131481@goodmis.org> <20170315200255.828608428@goodmis.org> X-Mailer: Sylpheed 3.5.0 (GTK+ 2.24.30; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 15 Mar 2017 15:55:32 -0400 Steven Rostedt wrote: > From: "Steven Rostedt (VMware)" > > x86_64 has had fentry support for some time. I did not add support to x86_32 > as I was unsure if it will be used much in the future. It is still very much > used, and there's issues with function graph tracing with gcc playing around > with the mcount frames, causing function graph to panic. The fentry code > does not have this issue, and is able to cope as there is no frame to mess > up. > > Note, this only add support for fentry when DYNAMIC_FTRACE is set. There's > really no reason to not have that set, because the performance of the > machine drops significantly when it's not enabled. I only keep > !DYNAMIC_FTRACE around to test it off, as there's still some archs that have > FTRACE but not DYNAMIC_FTRACE. > > Signed-off-by: Steven Rostedt (VMware) > --- > arch/x86/Kconfig | 2 +- > arch/x86/kernel/ftrace_32.S | 88 +++++++++++++++++++++++++++++++++++++++------ > 2 files changed, 79 insertions(+), 11 deletions(-) > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index cc98d5a294ee..8c17146427ca 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -127,7 +127,7 @@ config X86 > select HAVE_EBPF_JIT if X86_64 > select HAVE_EFFICIENT_UNALIGNED_ACCESS > select HAVE_EXIT_THREAD > - select HAVE_FENTRY if X86_64 > + select HAVE_FENTRY if X86_64 || DYNAMIC_FTRACE > select HAVE_FTRACE_MCOUNT_RECORD > select HAVE_FUNCTION_GRAPH_TRACER > select HAVE_FUNCTION_TRACER > diff --git a/arch/x86/kernel/ftrace_32.S b/arch/x86/kernel/ftrace_32.S > index 8ca33d9806ac..4bf8223555cd 100644 > --- a/arch/x86/kernel/ftrace_32.S > +++ b/arch/x86/kernel/ftrace_32.S > @@ -9,27 +9,75 @@ > #include > #include > > + > +#ifdef CC_USING_FENTRY > +# define function_hook __fentry__ > +EXPORT_SYMBOL(__fentry__) > +#else > +# define function_hook mcount > +EXPORT_SYMBOL(mcount) > +#endif > + > +/* mcount uses a frame pointer even if CONFIG_FRAME_POINTER is not set */ > +#if !defined(CC_USING_FENTRY) || defined(CONFIG_FRAME_POINTER) > +# define USING_FRAME_POINTER > +#endif > + > +#ifdef USING_FRAME_POINTER > +# ifdef CC_USING_FENTRY > +# define MCOUNT_FRAME_SIZE (4*4) /* bp,ip and parent's */ > +# else > +# define MCOUNT_FRAME_SIZE 4 /* just the bp */ > +# endif > +# define MCOUNT_FRAME 1 /* using frame = true */ > +#else > +# define MCOUNT_FRAME_SIZE 0 /* no stack frame */ > +# define MCOUNT_FRAME 0 /* using frame = false */ > +#endif It seems that there is no use of MCOUNT_FRAME_SIZE below. Do we really need it? Thanks, -- Masami Hiramatsu