[PATCH v2 1/2] arm64: implement FTRACE_WITH_REGS

[duwe@lst.de (Torsten Duwe)]

On Fri, Jul 08, 2016 at 05:08:08PM -0400, Steven Rostedt wrote:
> On Fri, 8 Jul 2016 22:24:55 +0200
> Torsten Duwe <duwe@lst.de> wrote:
> 
> > On Fri, Jul 08, 2016 at 11:57:10AM -0400, Steven Rostedt wrote:
> > > On Fri, 8 Jul 2016 10:48:24 -0500
> > > Josh Poimboeuf <jpoimboe@redhat.com> wrote:  
> > > > 
> > > > Here, with -fprolog-pad, it's already a nop, so no change is needed.
> > > >   
> > 
> > Yes, exactly.
> > 
> > > That's what I was thinking. But as I stated in another email (probably
> > > in the air when you wrote this), the call to ftrace_modify_code() may be
> > > completely circumvented by ftrace_make_nop() if the addr is MCOUNT_ADDR.  
> > 
> > Only on the _first_ invocation. Later on, tracing can be switched on and off,
> > and then the instructions need to be changed just like with fentry (or
> > profile-kernel ;-)
> > 
> 
> Understood, but ftrace_modify_code() will only receive addr ==
> MCOUNT_ADDR on boot up or when a module is loaded. In both cases, with
> -fprolog-pad it will already be a nop, hence no need to call
> ftrace_modify_code(), in those cases.
> 
> In all other cases, addr will point to a ftrace trampoline.

Maybe the code in question can be replaced with the change below, now that
there is a preprocessor define in V2?
(untested)

diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
index 3f743b1..695a646 100644
--- a/kernel/trace/ftrace.c
+++ b/kernel/trace/ftrace.c
@@ -2423,6 +2423,12 @@ ftrace_code_disable(struct module *mod, struct dyn_ftrace *rec)
 	if (unlikely(ftrace_disabled))
 		return 0;
 
+#ifdef CC_USING_PROLOG_PAD
+	/* If the compiler already generated NOPs instead of
+	 * calls to mcount, we're done here.
+	*/
+	return 1;
+#endif
 	ret = ftrace_make_nop(mod, rec, MCOUNT_ADDR);
 	if (ret) {
 		ftrace_bug(ret, rec);