From: Steven Rostedt <rostedt@goodmis.org>
To: Jiri Olsa <jolsa@redhat.com>
Cc: bpf@vger.kernel.org, linux-kernel@vger.kernel.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andriin@fb.com>
Subject: Re: [PATCH 7/8] ftrace: Add multi direct modify interface
Date: Wed, 15 Sep 2021 17:47:18 -0400 [thread overview]
Message-ID: <20210915174718.77acaf8b@gandalf.local.home> (raw)
In-Reply-To: <20210914174134.1d8fd944@oasis.local.home>
On Tue, 14 Sep 2021 17:41:34 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:
> A better solution, that prevents having to do this, is to first change
> the function fentry's to call the ftrace list loop function, that calls
> the ftrace_ops list, and will call the direct call via the ops in the
> loop. Have the ops->func call the new direct function (all will be
> immediately affected). Update the entries, and then switch from the
> loop back to the direct caller.
An easy way to force the loop function to be called instead of the direct
trampoline, is to register a stub ftrace_ops to each of the functions that
the direct function attaches to. You can even share the hash in doing so.
Having the ftrace_ops attached in the same locations as the direct
trampoline, will force the loop function to be called (to call the stub
ftrace_ops as well as the direct trampoline ftrace_ops helper).
Then change the direct trampoline address, which will have the ftrace_ops
helper use that direct trampoline immediately*. Then when you remove the
ftrace_ops stub, it will update all the call sites to call the new direct
trampoline directly.
(*) not quite immediately, as there's no read memory barrier with the
direct helper, so it may still be calling the old trampoline. But this
shouldn't be an issue. If it is, then you would need to include some memory
barrier synchronization.
I'm curious to what the use case is for the multi direct modify interface
is?
-- Steve
next prev parent reply other threads:[~2021-09-15 21:47 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-31 9:50 [PATCH 0/8] x86/ftrace: Add direct batch interface Jiri Olsa
2021-08-31 9:50 ` [PATCH 1/8] x86/ftrace: Remove extra orig rax move Jiri Olsa
2021-08-31 9:50 ` [PATCH 2/8] x86/ftrace: Remove fault protection code in prepare_ftrace_return Jiri Olsa
2021-08-31 9:50 ` [PATCH 3/8] x86/ftrace: Make function graph use ftrace directly Jiri Olsa
2021-08-31 9:50 ` [PATCH 4/8] tracing: Add trampoline/graph selftest Jiri Olsa
2021-08-31 9:50 ` [PATCH 5/8] ftrace: Add ftrace_add_rec_direct function Jiri Olsa
2021-08-31 9:50 ` [PATCH 6/8] ftrace: Add multi direct register/unregister interface Jiri Olsa
2021-09-14 21:35 ` Steven Rostedt
2021-09-16 19:45 ` Jiri Olsa
2021-08-31 9:50 ` [PATCH 7/8] ftrace: Add multi direct modify interface Jiri Olsa
2021-09-14 21:41 ` Steven Rostedt
2021-09-15 21:47 ` Steven Rostedt [this message]
2021-09-16 19:49 ` Jiri Olsa
2021-09-16 20:41 ` Steven Rostedt
2021-08-31 9:50 ` [PATCH 8/8] ftrace/samples: Add multi direct interface test module Jiri Olsa
2021-09-01 15:23 ` [PATCH 0/8] x86/ftrace: Add direct batch interface Alexei Starovoitov
2021-09-01 19:06 ` Jiri Olsa
2021-09-02 14:54 ` Steven Rostedt
2021-10-08 9:13 [PATCHv2 " Jiri Olsa
2021-10-08 9:13 ` [PATCH 7/8] ftrace: Add multi direct modify interface Jiri Olsa
2021-10-14 20:28 ` Steven Rostedt
2021-10-15 12:05 ` Jiri Olsa
2021-10-15 14:05 ` Steven Rostedt
2021-10-16 11:39 ` Jiri Olsa
2021-10-19 2:10 ` Steven Rostedt
2021-10-19 13:19 ` Jiri Olsa
2021-10-19 13:26 ` Jiri Olsa
2021-10-19 13:32 ` Steven Rostedt
2021-10-19 14:03 ` Jiri Olsa
2021-10-19 14:44 ` Steven Rostedt
2021-10-19 14:47 ` Jiri Olsa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210915174718.77acaf8b@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=andriin@fb.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).