On 29.03.2017 12:05, Miroslav Benes wrote:
On Wed, 29 Mar 2017, zhouchengming wrote:
On 2017/3/28 23:31, Evgenii Shatokhin wrote:
Hi,
I am not very familiar with the internals of ftrace, hence this question.
Suppose klp_ftrace_handler() is running on one CPU and, at the same time,
klp_disable_func() calls unregister_ftrace_function() and then
ftrace_set_filter_ip() on another CPU.
Is it guaranteed then, that by the time ftrace_set_filter_ip() returns,
klp_ftrace_handler() is no longer running?
Hi, if I understand your question correctly, I think you want to see this
comment in ftrace_shutdown() (called from unregister_ftrace_function())
/*
* 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 per_cpu
* 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 | FTRACE_OPS_FL_PER_CPU)) {
schedule_on_each_cpu(ftrace_sync);
arch_ftrace_trampoline_free(ops);
if (ops->flags & FTRACE_OPS_FL_PER_CPU)
per_cpu_ops_free(ops);
}
Thanks.
Correct. We rely on ftrace to do the right thing :). Which is not
guaranteed all the time, but it is in klp currently. See a discussion
which starts here
http://lkml.kernel.org/r/20161220173246.GC25166@xxxxxxxxxxxxxxx (and also
follow a link to my dialogue with Steven).
Yes, your discussion with Steven sheds more light on the matter. Thanks
a lot!
Regards,
Evgenii
--
To unsubscribe from this list: send the line "unsubscribe live-patching" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
