From: Masami Hiramatsu (Google) <mhiramat@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org, catalin.marinas@arm.com,
linux-arm-kernel@lists.infradead.org, mhiramat@kernel.org,
revest@chromium.org, rostedt@goodmis.org, will@kernel.org
Subject: Re: [PATCH v2 0/4] arm64/ftrace: move to DYNAMIC_FTRACE_WITH_ARGS
Date: Fri, 18 Nov 2022 09:04:05 +0900 [thread overview]
Message-ID: <20221118090405.5dc0c9f2caaec4e9720a47cd@kernel.org> (raw)
In-Reply-To: <20221103170520.931305-1-mark.rutland@arm.com>
On Thu, 3 Nov 2022 17:05:16 +0000
Mark Rutland <mark.rutland@arm.com> wrote:
> This series replaces arm64's support for FTRACE_WITH_REGS with support
> for FTRACE_WITH_ARGS. This removes some overhead and complexity, and
> removes some latent issues with inconsistent presentation of struct
> pt_regs (which can only be reliably saved/restored at exception
> boundaries).
>
> The existing FTRACE_WITH_REGS support was added for two major reasons:
>
> (1) To make it possible to use the ftrace graph tracer with pointer
> authentication, where it's necessary to snapshot/manipulate the LR
> before it is signed by the instrumented function.
>
> (2) To make it possible to implement LIVEPATCH in future, where we need
> to hook function entry before an instrumented function manipulates
> the stack or argument registers. Practically speaking, we need to
> preserve the argument/return registers, PC, LR, and SP.
>
> Neither of these requires the full set of pt_regs, and only requires us
> to save/restore a subset of registers used for passing
> arguments/return-values and context/return information (which is the
> minimum set we always need to save/restore today).
>
> As there is no longer a need to save different sets of registers for
> different features, we no longer need distinct `ftrace_caller` and
> `ftrace_regs_caller` trampolines. This allows the trampoline assembly to
> be simpler, and simplifies code which previously had to handle the two
> trampolines.
>
> I've tested this with the ftrace selftests, where there are no
> unexpected failures.
>
> I plan to build atop this with subsequent patches to add per-callsite
> ftrace_ops, and I'm sending these patches on their own as I think they
> make sense regardless.
Thanks! this series looks good to me.
Reviewed-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
So it is the good time to rewrite the new fprobe event handler
based on these interfaces :)
>
> Since v1 [1]:
> * Change ifdeferry per Steve's request
> * Add ftrace_regs_query_register_offset() per Masami's request
> * Fix a bunch of typos
>
> [1] https://lore.kernel.org/lkml/20221024140846.3555435-1-mark.rutland@arm.com
>
> This series can be found in my 'arm64/ftrace/minimal-regs' branch on
> kernel.org:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git/
> git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
>
> This version is tagged as:
>
> arm64-ftrace-minimal-regs-20221103
>
> Thanks,
> Mark.
>
> Mark Rutland (4):
> ftrace: pass fregs to arch_ftrace_set_direct_caller()
> ftrace: rename ftrace_instruction_pointer_set() ->
> ftrace_regs_set_instruction_pointer()
> ftrace: abstract DYNAMIC_FTRACE_WITH_ARGS accesses
> ftrace: arm64: move from REGS to ARGS
>
> arch/arm64/Kconfig | 18 +++--
> arch/arm64/Makefile | 2 +-
> arch/arm64/include/asm/ftrace.h | 72 ++++++++++++++++--
> arch/arm64/kernel/asm-offsets.c | 13 ++++
> arch/arm64/kernel/entry-ftrace.S | 117 ++++++++++++------------------
> arch/arm64/kernel/ftrace.c | 82 ++++++++++++---------
> arch/arm64/kernel/module.c | 3 -
> arch/powerpc/include/asm/ftrace.h | 24 +++++-
> arch/s390/include/asm/ftrace.h | 29 +++++++-
> arch/x86/include/asm/ftrace.h | 49 +++++++++----
> include/linux/ftrace.h | 47 +++++++++---
> kernel/livepatch/patch.c | 2 +-
> kernel/trace/Kconfig | 6 +-
> kernel/trace/ftrace.c | 3 +-
> 14 files changed, 309 insertions(+), 158 deletions(-)
>
> --
> 2.30.2
>
--
Masami Hiramatsu (Google) <mhiramat@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-11-18 0:05 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-03 17:05 [PATCH v2 0/4] arm64/ftrace: move to DYNAMIC_FTRACE_WITH_ARGS Mark Rutland
2022-11-03 17:05 ` [PATCH v2 1/4] ftrace: pass fregs to arch_ftrace_set_direct_caller() Mark Rutland
2022-11-03 17:05 ` [PATCH v2 2/4] ftrace: rename ftrace_instruction_pointer_set() -> ftrace_regs_set_instruction_pointer() Mark Rutland
2022-11-03 17:05 ` [PATCH v2 3/4] ftrace: abstract DYNAMIC_FTRACE_WITH_ARGS accesses Mark Rutland
2022-11-03 17:05 ` [PATCH v2 4/4] ftrace: arm64: move from REGS to ARGS Mark Rutland
2022-11-15 11:27 ` Will Deacon
2022-11-17 10:52 ` Mark Rutland
2022-11-18 12:31 ` Will Deacon
2022-11-18 13:57 ` Mark Rutland
2022-11-18 14:09 ` Will Deacon
2022-11-15 15:01 ` [PATCH v2 0/4] arm64/ftrace: move to DYNAMIC_FTRACE_WITH_ARGS Steven Rostedt
2022-11-15 15:48 ` Mark Rutland
2022-11-18 0:04 ` Masami Hiramatsu [this message]
2022-11-18 19:40 ` Will Deacon
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=20221118090405.5dc0c9f2caaec4e9720a47cd@kernel.org \
--to=mhiramat@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=revest@chromium.org \
--cc=rostedt@goodmis.org \
--cc=will@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).