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
WARNING: multiple messages have this Message-ID (diff)
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>
next prev parent reply other threads:[~2022-11-18 0:05 UTC|newest]
Thread overview: 28+ 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 ` 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 ` 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 ` 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 ` Mark Rutland
2022-11-03 17:05 ` [PATCH v2 4/4] ftrace: arm64: move from REGS to ARGS Mark Rutland
2022-11-03 17:05 ` Mark Rutland
2022-11-15 11:27 ` Will Deacon
2022-11-15 11:27 ` Will Deacon
2022-11-17 10:52 ` Mark Rutland
2022-11-17 10:52 ` Mark Rutland
2022-11-18 12:31 ` Will Deacon
2022-11-18 12:31 ` Will Deacon
2022-11-18 13:57 ` Mark Rutland
2022-11-18 13:57 ` Mark Rutland
2022-11-18 14:09 ` Will Deacon
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:01 ` Steven Rostedt
2022-11-15 15:48 ` Mark Rutland
2022-11-15 15:48 ` Mark Rutland
2022-11-18 0:04 ` Masami Hiramatsu [this message]
2022-11-18 0:04 ` Masami Hiramatsu
2022-11-18 19:40 ` Will Deacon
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.