All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Rutland <mark.rutland@arm.com>
To: Florent Revest <revest@chromium.org>,
	catalin.marinas@arm.com, will@kernel.org, rostedt@goodmis.org
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org, mhiramat@kernel.org, ast@kernel.org,
	daniel@iogearbox.net, andrii@kernel.org, kpsingh@kernel.org,
	jolsa@kernel.org, xukuohai@huaweicloud.com, lihuafei1@huawei.com
Subject: Re: [PATCH v6 0/5] Add ftrace direct call for arm64
Date: Tue, 11 Apr 2023 16:56:45 +0100	[thread overview]
Message-ID: <ZDWDPUY2tZiMbk8V@FVFF77S0Q05N> (raw)
In-Reply-To: <20230405180250.2046566-1-revest@chromium.org>

On Wed, Apr 05, 2023 at 08:02:45PM +0200, Florent Revest wrote:
> This series adds ftrace direct call support to arm64.
> This makes BPF tracing programs (fentry/fexit/fmod_ret/lsm) work on arm64.
> 
> It is meant to be taken by the arm64 tree but it depends on the
> trace-direct-v6.3-rc3 tag of the linux-trace tree:
>   git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
> That tag was created by Steven Rostedt so the arm64 tree can pull the prior work
> this depends on. [1]

Catalin, Will, are you happy to pick this via the arm64 tree, or for it to go
via the trace tree?

We'd been assuming the former, but it looks like there'll be a (simple) merge
conflict with the series adding FUNCTION_GRAPH_RETVAL:

  https://lore.kernel.org/lkml/cover.1680954589.git.pengdonglin@sangfor.com.cn/

... as both series add some definitions to arm64's asm-offsets.c in the same
place, and all those additions need to be kept. Other than that, the two series
are independent.

IIUC Steve was hoping to take the FUNCTION_GRAPH_RETVAL series through the
trace tree, and if that's still the plan, maybe both should go that way?

Mark.

> Thanks to the ftrace refactoring under that tag, an ftrace_ops backing a ftrace
> direct call will only ever point to *one* direct call. This means we can look up
> the direct called trampoline address stored in the ops from the ftrace_caller
> trampoline in the case when the destination would be out of reach of a BL
> instruction at the ftrace callsite. This fixes limitations of previous attempts
> such as [2].
> 
> This series has been tested on arm64 with:
> 1- CONFIG_FTRACE_SELFTEST
> 2- samples/ftrace/*.ko (cf: patch 4)
> 3- tools/testing/selftests/bpf/test_progs (cf: patch 5)
> 
> Changes since v5 [3]:
> - Fixed saving the fourth argument of handle_mm_fault in both the x86 (patch 3)
>   and arm64 (as part of patch 4) "ftrace-direct-too" sample trampolines
> - Fixed the address of the traced function logged by some direct call samples
>   (ftrace-direct-multi and ftrace-direct-multi-modify) by moving lr into x0
> 
> 1: https://lore.kernel.org/all/ZB2Nl7fzpHoq5V20@FVFF77S0Q05N/
> 2: https://lore.kernel.org/all/20220913162732.163631-1-xukuohai@huaweicloud.com/
> 3: https://lore.kernel.org/bpf/20230403113552.2857693-1-revest@chromium.org/
> 
> Florent Revest (5):
>   arm64: ftrace: Add direct call support
>   arm64: ftrace: Simplify get_ftrace_plt
>   samples: ftrace: Save required argument registers in sample
>     trampolines
>   arm64: ftrace: Add direct call trampoline samples support
>   selftests/bpf: Update the tests deny list on aarch64
> 
>  arch/arm64/Kconfig                           |  6 ++
>  arch/arm64/include/asm/ftrace.h              | 22 +++++
>  arch/arm64/kernel/asm-offsets.c              |  6 ++
>  arch/arm64/kernel/entry-ftrace.S             | 90 ++++++++++++++++----
>  arch/arm64/kernel/ftrace.c                   | 46 +++++++---
>  samples/ftrace/ftrace-direct-modify.c        | 34 ++++++++
>  samples/ftrace/ftrace-direct-multi-modify.c  | 40 +++++++++
>  samples/ftrace/ftrace-direct-multi.c         | 24 ++++++
>  samples/ftrace/ftrace-direct-too.c           | 40 +++++++--
>  samples/ftrace/ftrace-direct.c               | 24 ++++++
>  tools/testing/selftests/bpf/DENYLIST.aarch64 | 82 ++----------------
>  11 files changed, 306 insertions(+), 108 deletions(-)
> 
> -- 
> 2.40.0.577.gac1e443424-goog
> 

WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Florent Revest <revest@chromium.org>,
	catalin.marinas@arm.com, will@kernel.org, rostedt@goodmis.org
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-trace-kernel@vger.kernel.org,
	bpf@vger.kernel.org, mhiramat@kernel.org, ast@kernel.org,
	daniel@iogearbox.net, andrii@kernel.org, kpsingh@kernel.org,
	jolsa@kernel.org, xukuohai@huaweicloud.com, lihuafei1@huawei.com
Subject: Re: [PATCH v6 0/5] Add ftrace direct call for arm64
Date: Tue, 11 Apr 2023 16:56:45 +0100	[thread overview]
Message-ID: <ZDWDPUY2tZiMbk8V@FVFF77S0Q05N> (raw)
In-Reply-To: <20230405180250.2046566-1-revest@chromium.org>

On Wed, Apr 05, 2023 at 08:02:45PM +0200, Florent Revest wrote:
> This series adds ftrace direct call support to arm64.
> This makes BPF tracing programs (fentry/fexit/fmod_ret/lsm) work on arm64.
> 
> It is meant to be taken by the arm64 tree but it depends on the
> trace-direct-v6.3-rc3 tag of the linux-trace tree:
>   git://git.kernel.org/pub/scm/linux/kernel/git/trace/linux-trace.git
> That tag was created by Steven Rostedt so the arm64 tree can pull the prior work
> this depends on. [1]

Catalin, Will, are you happy to pick this via the arm64 tree, or for it to go
via the trace tree?

We'd been assuming the former, but it looks like there'll be a (simple) merge
conflict with the series adding FUNCTION_GRAPH_RETVAL:

  https://lore.kernel.org/lkml/cover.1680954589.git.pengdonglin@sangfor.com.cn/

... as both series add some definitions to arm64's asm-offsets.c in the same
place, and all those additions need to be kept. Other than that, the two series
are independent.

IIUC Steve was hoping to take the FUNCTION_GRAPH_RETVAL series through the
trace tree, and if that's still the plan, maybe both should go that way?

Mark.

> Thanks to the ftrace refactoring under that tag, an ftrace_ops backing a ftrace
> direct call will only ever point to *one* direct call. This means we can look up
> the direct called trampoline address stored in the ops from the ftrace_caller
> trampoline in the case when the destination would be out of reach of a BL
> instruction at the ftrace callsite. This fixes limitations of previous attempts
> such as [2].
> 
> This series has been tested on arm64 with:
> 1- CONFIG_FTRACE_SELFTEST
> 2- samples/ftrace/*.ko (cf: patch 4)
> 3- tools/testing/selftests/bpf/test_progs (cf: patch 5)
> 
> Changes since v5 [3]:
> - Fixed saving the fourth argument of handle_mm_fault in both the x86 (patch 3)
>   and arm64 (as part of patch 4) "ftrace-direct-too" sample trampolines
> - Fixed the address of the traced function logged by some direct call samples
>   (ftrace-direct-multi and ftrace-direct-multi-modify) by moving lr into x0
> 
> 1: https://lore.kernel.org/all/ZB2Nl7fzpHoq5V20@FVFF77S0Q05N/
> 2: https://lore.kernel.org/all/20220913162732.163631-1-xukuohai@huaweicloud.com/
> 3: https://lore.kernel.org/bpf/20230403113552.2857693-1-revest@chromium.org/
> 
> Florent Revest (5):
>   arm64: ftrace: Add direct call support
>   arm64: ftrace: Simplify get_ftrace_plt
>   samples: ftrace: Save required argument registers in sample
>     trampolines
>   arm64: ftrace: Add direct call trampoline samples support
>   selftests/bpf: Update the tests deny list on aarch64
> 
>  arch/arm64/Kconfig                           |  6 ++
>  arch/arm64/include/asm/ftrace.h              | 22 +++++
>  arch/arm64/kernel/asm-offsets.c              |  6 ++
>  arch/arm64/kernel/entry-ftrace.S             | 90 ++++++++++++++++----
>  arch/arm64/kernel/ftrace.c                   | 46 +++++++---
>  samples/ftrace/ftrace-direct-modify.c        | 34 ++++++++
>  samples/ftrace/ftrace-direct-multi-modify.c  | 40 +++++++++
>  samples/ftrace/ftrace-direct-multi.c         | 24 ++++++
>  samples/ftrace/ftrace-direct-too.c           | 40 +++++++--
>  samples/ftrace/ftrace-direct.c               | 24 ++++++
>  tools/testing/selftests/bpf/DENYLIST.aarch64 | 82 ++----------------
>  11 files changed, 306 insertions(+), 108 deletions(-)
> 
> -- 
> 2.40.0.577.gac1e443424-goog
> 

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2023-04-11 15:56 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-04-05 18:02 [PATCH v6 0/5] Add ftrace direct call for arm64 Florent Revest
2023-04-05 18:02 ` Florent Revest
2023-04-05 18:02 ` [PATCH v6 1/5] arm64: ftrace: Add direct call support Florent Revest
2023-04-05 18:02   ` Florent Revest
2023-04-05 18:02 ` [PATCH v6 2/5] arm64: ftrace: Simplify get_ftrace_plt Florent Revest
2023-04-05 18:02   ` Florent Revest
2023-04-05 18:02 ` [PATCH v6 3/5] samples: ftrace: Save required argument registers in sample trampolines Florent Revest
2023-04-05 18:02   ` Florent Revest
2023-04-05 20:40   ` Steven Rostedt
2023-04-05 20:40     ` Steven Rostedt
2023-04-06 10:22   ` Mark Rutland
2023-04-06 10:22     ` Mark Rutland
2023-04-05 18:02 ` [PATCH v6 4/5] arm64: ftrace: Add direct call trampoline samples support Florent Revest
2023-04-05 18:02   ` Florent Revest
2023-04-06 10:50   ` Mark Rutland
2023-04-06 10:50     ` Mark Rutland
2023-04-05 18:02 ` [PATCH v6 5/5] selftests/bpf: Update the tests deny list on aarch64 Florent Revest
2023-04-05 18:02   ` Florent Revest
2023-04-11 15:56 ` Mark Rutland [this message]
2023-04-11 15:56   ` [PATCH v6 0/5] Add ftrace direct call for arm64 Mark Rutland
2023-04-11 16:47   ` Steven Rostedt
2023-04-11 16:47     ` Steven Rostedt
2023-04-11 17:08     ` Will Deacon
2023-04-11 17:08       ` Will Deacon
2023-04-11 17:44       ` Steven Rostedt
2023-04-11 17:44         ` Steven Rostedt
2023-04-11 17:54         ` Will Deacon
2023-04-11 17:54           ` Will Deacon
2023-04-12  9:50           ` Mark Rutland
2023-04-12  9:50             ` Mark Rutland
2023-04-24 20:09             ` Steven Rostedt
2023-04-24 20:09               ` Steven Rostedt
2023-04-11 18:37 ` Will Deacon
2023-04-11 18:37   ` 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=ZDWDPUY2tZiMbk8V@FVFF77S0Q05N \
    --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=lihuafei1@huawei.com \
    --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 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.