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@xxxxxx> 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@xxxxxxxxxx> 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);
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
