mbox series

[0/8] x86/ftrace: Add direct batch interface

Message ID 20210831095017.412311-1-jolsa@kernel.org (mailing list archive)
Headers show
Series x86/ftrace: Add direct batch interface | expand

Message

Jiri Olsa Aug. 31, 2021, 9:50 a.m. UTC
hi,
adding interface to maintain multiple direct functions
within single calls. It's a base for follow up bpf batch
attach functionality.

New interface:

  int register_ftrace_direct_multi(struct ftrace_ops *ops, unsigned long addr)
  int unregister_ftrace_direct_multi(struct ftrace_ops *ops)
  int modify_ftrace_direct_multi(struct ftrace_ops *ops, unsigned long addr)

that allows to register/unregister/modify direct function 'addr'
with struct ftrace_ops object. The ops filter can be updated
before with ftrace_set_filter_ip calls

  1) patches (1-4) that fix the ftrace graph tracing over the function
     with direct trampolines attached
  2) patches (5-8) that add batch interface for ftrace direct function
     register/unregister/modify

Also available at (based on Steven's ftrace/core branch):
  https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
  ftrace/direct

thanks,
jirka


---
Jiri Olsa (6):
      x86/ftrace: Remove extra orig rax move
      tracing: Add trampoline/graph selftest
      ftrace: Add ftrace_add_rec_direct function
      ftrace: Add multi direct register/unregister interface
      ftrace: Add multi direct modify interface
      ftrace/samples: Add multi direct interface test module

Steven Rostedt (VMware) (2):
      x86/ftrace: Remove fault protection code in prepare_ftrace_return
      x86/ftrace: Make function graph use ftrace directly

 arch/x86/include/asm/ftrace.h        |   9 +++--
 arch/x86/kernel/ftrace.c             |  71 +++++++++++++++++++-------------------
 arch/x86/kernel/ftrace_64.S          |  30 +---------------
 include/linux/ftrace.h               |  26 ++++++++++++++
 kernel/trace/fgraph.c                |   6 ++--
 kernel/trace/ftrace.c                | 214 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-------------
 kernel/trace/trace_selftest.c        |  49 +++++++++++++++++++++++++-
 samples/ftrace/Makefile              |   1 +
 samples/ftrace/ftrace-direct-multi.c |  52 ++++++++++++++++++++++++++++
 9 files changed, 364 insertions(+), 94 deletions(-)
 create mode 100644 samples/ftrace/ftrace-direct-multi.c

Comments

Alexei Starovoitov Sept. 1, 2021, 3:23 p.m. UTC | #1
On Tue, Aug 31, 2021 at 2:50 AM Jiri Olsa <jolsa@redhat.com> wrote:
>
> hi,
> adding interface to maintain multiple direct functions
> within single calls. It's a base for follow up bpf batch
> attach functionality.
>
> New interface:
>
>   int register_ftrace_direct_multi(struct ftrace_ops *ops, unsigned long addr)
>   int unregister_ftrace_direct_multi(struct ftrace_ops *ops)
>   int modify_ftrace_direct_multi(struct ftrace_ops *ops, unsigned long addr)
>
> that allows to register/unregister/modify direct function 'addr'
> with struct ftrace_ops object. The ops filter can be updated
> before with ftrace_set_filter_ip calls
>
>   1) patches (1-4) that fix the ftrace graph tracing over the function
>      with direct trampolines attached
>   2) patches (5-8) that add batch interface for ftrace direct function
>      register/unregister/modify
>
> Also available at (based on Steven's ftrace/core branch):
>   https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
>   ftrace/direct

Steven,

Could you review and merge this set for this merge window,
so we can process related bpf bits for the next cycle?
Jiri Olsa Sept. 1, 2021, 7:06 p.m. UTC | #2
On Wed, Sep 01, 2021 at 08:23:38AM -0700, Alexei Starovoitov wrote:
> On Tue, Aug 31, 2021 at 2:50 AM Jiri Olsa <jolsa@redhat.com> wrote:
> >
> > hi,
> > adding interface to maintain multiple direct functions
> > within single calls. It's a base for follow up bpf batch
> > attach functionality.
> >
> > New interface:
> >
> >   int register_ftrace_direct_multi(struct ftrace_ops *ops, unsigned long addr)
> >   int unregister_ftrace_direct_multi(struct ftrace_ops *ops)
> >   int modify_ftrace_direct_multi(struct ftrace_ops *ops, unsigned long addr)
> >
> > that allows to register/unregister/modify direct function 'addr'
> > with struct ftrace_ops object. The ops filter can be updated
> > before with ftrace_set_filter_ip calls
> >
> >   1) patches (1-4) that fix the ftrace graph tracing over the function
> >      with direct trampolines attached
> >   2) patches (5-8) that add batch interface for ftrace direct function
> >      register/unregister/modify
> >
> > Also available at (based on Steven's ftrace/core branch):
> >   https://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
> >   ftrace/direct
> 
> Steven,
> 
> Could you review and merge this set for this merge window,
> so we can process related bpf bits for the next cycle?

actually I might have sent it out too early, there's still
bpf part review discussion that might end up in interface
change

review would be great, but please hold on with the merge

thanks,
jirka
Steven Rostedt Sept. 2, 2021, 2:54 p.m. UTC | #3
On Wed, 1 Sep 2021 21:06:45 +0200 Jiri Olsa <jolsa@redhat.com> wrote:
> On Wed, Sep 01, 2021 at 08:23:38AM -0700, Alexei Starovoitov wrote:

> > Steven,
> > 
> > Could you review and merge this set for this merge window,
> > so we can process related bpf bits for the next cycle?  
> 
> actually I might have sent it out too early, there's still
> bpf part review discussion that might end up in interface
> change

Regardless, it is way too late to apply this to the current merge
window. I don't think Linus would appreciate me pulling in a complex
patch set 4 days into the merge window, review it, and then push it to
him without much faith that this wont cause any major issues in use
cases we did not think about. Not to mention, I would have to drop
everything I am responsible for to do that.

I would never ask another maintainer to do such an irresponsible act.

> 
> review would be great, but please hold on with the merge

I just got back from an 8 day vacation, and my inbox is way out of
hand, and I still need to put together the changes that have been in
linux-next for some time, and get that to Linus.

Hopefully I'll get to looking at this sometime next week.

-- Steve