On Sun, 30 Mar 2014 20:39:50 +0100 Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote: > On Tue, 2014-02-11 at 14:49 -0500, Steven Rostedt wrote: > > commit a4c35ed241129dd142be4cadb1e5a474a56d5464 upstream. > > > > The synchronization needed after ftrace_ops are unregistered must happen > > after the callback is disabled from becing called by functions. > > > > The current location happens after the function is being removed from the > > internal lists, but not after the function callbacks were disabled, leaving > > the functions susceptible of being called after their callbacks are freed. > > > > This affects perf and any externel users of function tracing (LTTng and > > SystemTap). > > > > Cc: stable@xxxxxxxxxxxxxxx # 3.0+ > > Fixes: cdbe61bfe704 "ftrace: Allow dynamically allocated function tracers" > > Signed-off-by: Steven Rostedt <rostedt@xxxxxxxxxxx> > [...] > > I've queued this up for 3.2, but I needed to make further changes. My > version is below. I tried a backport, and got something almost identical. > + > + /* > + * Dynamic ops may be freed, we must make sure that all > + * callers are done before leaving this function. > + * The same goes for freeing the per_cpu data of the control > + * ops. > + * > + * Again, normal synchronize_sched() is not good enough. > + * We need to do a hard force of sched synchronization. > + * This is because we use preempt_disable() to do RCU, but > + * the function tracers can be called where RCU is not watching > + * (like before user_exit()). We can not rely on the RCU > + * infrastructure to do the synchronization, thus we must do it > + * ourselves. > + */ > + if (ops->flags & (FTRACE_OPS_FL_DYNAMIC)) The only difference was that I didn't have the parenthesis around the above flag. No big deal, as the result is the same. Acked-by: Steven Rostedt <rostedt@xxxxxxxxxxx> -- Steve > + schedule_on_each_cpu(ftrace_sync); > + > return 0; > } > > > -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html