From: Mark Rutland <mark.rutland@arm.com>
To: Florent Revest <revest@chromium.org>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
bpf@vger.kernel.org, catalin.marinas@arm.com, will@kernel.org,
rostedt@goodmis.org, mhiramat@kernel.org, ast@kernel.org,
daniel@iogearbox.net, andrii@kernel.org, kpsingh@kernel.org,
jolsa@kernel.org, xukuohai@huaweicloud.com
Subject: Re: [PATCH 4/8] ftrace: Store direct called addresses in their ops
Date: Thu, 2 Feb 2023 15:29:59 +0000 [thread overview]
Message-ID: <Y9vW99htjOphDXqY@FVFF77S0Q05N.cambridge.arm.com> (raw)
In-Reply-To: <20230201163420.1579014-5-revest@chromium.org>
On Wed, Feb 01, 2023 at 05:34:16PM +0100, Florent Revest wrote:
> All direct calls are now registered using the register_ftrace_direct API
> so each ops can jump to only one direct-called trampoline.
>
> By storing the direct called trampoline address directly in the ops we
> can save one hashmap lookup in the direct call ops and implement arm64
> direct calls on top of call ops.
>
> Signed-off-by: Florent Revest <revest@chromium.org>
> ---
> include/linux/ftrace.h | 3 +++
> kernel/trace/ftrace.c | 6 ++++--
> 2 files changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index a7dbd307c3a4..84f717f8959e 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -321,6 +321,9 @@ struct ftrace_ops {
> unsigned long trampoline_size;
> struct list_head list;
> ftrace_ops_func_t ops_func;
> +#ifdef CONFIG_DYNAMIC_FTRACE_WITH_DIRECT_CALLS
> + unsigned long direct_call;
> +#endif
> #endif
> };
>
> diff --git a/kernel/trace/ftrace.c b/kernel/trace/ftrace.c
> index cb77a0a208c7..b0426de11c45 100644
> --- a/kernel/trace/ftrace.c
> +++ b/kernel/trace/ftrace.c
> @@ -2577,9 +2577,8 @@ ftrace_add_rec_direct(unsigned long ip, unsigned long addr,
> static void call_direct_funcs(unsigned long ip, unsigned long pip,
> struct ftrace_ops *ops, struct ftrace_regs *fregs)
> {
> - unsigned long addr;
> + unsigned long addr = ops->direct_call;
>
> - addr = ftrace_find_rec_direct(ip);
> if (!addr)
> return;
>
> @@ -5375,6 +5374,7 @@ int register_ftrace_direct(struct ftrace_ops *ops, unsigned long addr)
> ops->func = call_direct_funcs;
> ops->flags = MULTI_FLAGS;
> ops->trampoline = FTRACE_REGS_ADDR;
> + ops->direct_call = addr;
>
> err = register_ftrace_function_nolock(ops);
>
> @@ -5445,6 +5445,7 @@ __modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr)
> /* Enable the tmp_ops to have the same functions as the direct ops */
> ftrace_ops_init(&tmp_ops);
> tmp_ops.func_hash = ops->func_hash;
> + tmp_ops.direct_call = addr;
>
> err = register_ftrace_function_nolock(&tmp_ops);
> if (err)
> @@ -5466,6 +5467,7 @@ __modify_ftrace_direct(struct ftrace_ops *ops, unsigned long addr)
> entry->direct = addr;
> }
> }
> + ops->direct_call = addr;
AFAICT we don't synchronize threads when installing the tmp_ops, so IIUC on
arches with call_ops, there could be a a thread in the middle of ftrace_caller
which has loaded the ops pointer from the patch-site, but hasn't yet loaded the
ops::direct_func pointer, and could race with this assignment.
Given that, I think this needs to be:
WRITE_ONCE(ops->direct_call, addr);
... in order to avoid the risk of the store being torn, and the ftrace_caller
trampoline loading a corrupted pointer.
Other than that, this looks good to me!
Thanks,
Mark.
>
> mutex_unlock(&ftrace_lock);
>
> --
> 2.39.1.519.gcb327c4b5f-goog
>
next prev parent reply other threads:[~2023-02-02 15:33 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-02-01 16:34 [PATCH 0/8] Add ftrace direct call for arm64 Florent Revest
2023-02-01 16:34 ` [PATCH 1/8] ftrace: Replace uses of _ftrace_direct APIs with _ftrace_direct_multi Florent Revest
2023-02-02 15:01 ` Mark Rutland
2023-02-02 17:37 ` Florent Revest
2023-02-07 15:21 ` Florent Revest
2023-02-07 15:35 ` Steven Rostedt
2023-02-07 16:19 ` Florent Revest
2023-02-01 16:34 ` [PATCH 2/8] ftrace: Remove the legacy _ftrace_direct API Florent Revest
2023-02-02 15:11 ` Mark Rutland
2023-02-01 16:34 ` [PATCH 3/8] ftrace: Rename _ftrace_direct_multi APIs to _ftrace_direct APIs Florent Revest
2023-02-02 15:17 ` Mark Rutland
2023-02-01 16:34 ` [PATCH 4/8] ftrace: Store direct called addresses in their ops Florent Revest
2023-02-02 15:29 ` Mark Rutland [this message]
2023-02-02 17:41 ` Florent Revest
2023-02-01 16:34 ` [PATCH 5/8] ftrace: Make DIRECT_CALLS work WITH_ARGS and !WITH_REGS Florent Revest
2023-02-02 15:54 ` Mark Rutland
2023-02-02 16:56 ` Mark Rutland
2023-02-02 18:19 ` Florent Revest
2023-02-03 10:03 ` Mark Rutland
2023-02-03 11:01 ` Florent Revest
2023-02-02 18:18 ` Florent Revest
2023-02-01 16:34 ` [PATCH 6/8] ftrace: Fix dead loop caused by direct call in ftrace selftest Florent Revest
2023-02-02 19:03 ` Mark Rutland
2023-02-03 12:35 ` Florent Revest
2023-02-03 15:37 ` Mark Rutland
2023-02-06 16:25 ` Florent Revest
2023-02-01 16:34 ` [PATCH 7/8] arm64: ftrace: Add direct call support Florent Revest
2023-02-03 15:34 ` Mark Rutland
2023-02-06 16:25 ` Florent Revest
2023-02-01 16:34 ` [PATCH 8/8] arm64: ftrace: Add direct called trampoline samples support Florent Revest
2023-02-02 8:36 ` [PATCH 0/8] Add ftrace direct call for arm64 Xu Kuohai
2023-02-02 10:50 ` Daniel Borkmann
2023-02-02 17:32 ` Florent Revest
2023-02-02 20:06 ` Steven Rostedt
2023-02-03 9:49 ` Mark Rutland
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=Y9vW99htjOphDXqY@FVFF77S0Q05N.cambridge.arm.com \
--to=mark.rutland@arm.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=daniel@iogearbox.net \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=revest@chromium.org \
--cc=rostedt@goodmis.org \
--cc=will@kernel.org \
--cc=xukuohai@huaweicloud.com \
/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).