[lkml]   [2019]   [Nov]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH 03/10] ftrace: Add register_ftrace_direct()
On Fri, Nov 08, 2019 at 04:28:37PM -0500, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" <>
> Add the start of the functionality to allow other trampolines to use the
> ftrace mcount/fentry/nop location. This adds two new functions:
> register_ftrace_direct() and unregister_ftrace_direct()
> Both take two parameters: the first is the instruction address of where the
> mcount/fentry/nop exists, and the second is the trampoline to have that
> location called.
> This will handle cases where ftrace is already used on that same location,
> and will make it still work, where the registered direct called trampoline
> will get called after all the registered ftrace callers are handled.
> Currently, it will not allow for IP_MODIFY functions to be called at the
> same locations, which include some kprobes and live kernel patching.
> At this point, no architecture supports this. This is only the start of
> implementing the framework.
> Signed-off-by: Steven Rostedt (VMware) <>
> +struct ftrace_ops direct_ops = {
> + .func = call_direct_funcs,
> +};

The whole set looks great. Thank you for adding FL_PERMANENT to it.
Is there a way to do a replacement of direct call?
If I use unregister(old)+register(new) some events will be missed.
If I use register(new)+unregister(old) for short period of time both new and
old will be triggering on all cpus which will likely confuse bpf tracing.
Something like modify_ftrace_direct() should solve it. It's still racy. In a
sense that some cpus will be executing old while other cpus will be executing
new, but per-cpu there will be no double accounting. How difficult would be
to add such feature?

 \ /
  Last update: 2019-11-09 03:29    [W:0.016 / U:64.860 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site