Question about ftrace, dynamically allocated trampolines and dynamic fops

[Miroslav Benes]

Hi,

solving a possible race condition in kGraft and thinking about the same in 
klp live patching I looked quite a lot at ftrace code. One thing about 
recent dynamic trampolines seems a bit odd. For dynamic fops 
(FTRACE_OPS_FL_DYNAMIC is set in ops->flags) arch_ftrace_update_trampoline 
is called only for nonpreemptive kernels in ftrace_update_trampoline. The 
reason is obvious and well described in the comment there. However the 
actual callback function in arch_ftrace_update_trampoline is 
determined by call to ftrace_ops_get_func which gives generic 
ftrace_ops_list_func for dynamic ops. This function disables preemption 
(because of traversing rcu protected list), so it should be safe to use 
dynamic trampolines even for dynamic fops in preemptive kernels. Is this 
correct? 

Or maybe the problem is the opposite. Why does the ftrace use 
ftrace_ops_list_func in such situation? Even for nonpreemptive kernel and 
dynamic fops ftrace_ops_list_func has unnecessary overhead.

I'm almost sure I must have missed something but I cannot see what. Could 
you point me at the right direction?

Thanks a lot in advance,
--
Miroslav Benes
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/