[PATCH 0/2] arm64: ftrace: enable single ftrace_ops for direct calls

[PATCH 0/2] arm64: ftrace: enable single ftrace_ops for direct calls

[Leon Hwang]

Beyond the DIRECT_CALLS support on arm64 [1], select
HAVE_SINGLE_FTRACE_DIRECT_OPS for arm64, which enables the BPF
tracing_multi link on arm64 [2].

All tracing_multi link selftests are passed on arm64.

 cd tools/testing/selftests/bpf
 ./test_progs -a 'tracing_multi_*'
 #545/1   tracing_multi_attach_rollback/put:OK
 #545/2   tracing_multi_attach_rollback/unlink:OK
 #545     tracing_multi_attach_rollback:OK
 #546     tracing_multi_bench_attach:OK
 #547/1   tracing_multi_test/skel_api:OK
 #547/2   tracing_multi_test/link_api_pattern:OK
 #547/3   tracing_multi_test/link_api_ids:OK
 #547/4   tracing_multi_test/module_skel_api:OK
 #547/5   tracing_multi_test/module_link_api_pattern:OK
 #547/6   tracing_multi_test/module_link_api_ids:OK
 #547/7   tracing_multi_test/intersect:OK
 #547/8   tracing_multi_test/cookies:OK
 #547/9   tracing_multi_test/session:OK
 #547/10  tracing_multi_test/attach_api_fails:OK
 #547/11  tracing_multi_test/fentry_direct_access:OK
 #547/12  tracing_multi_test/fexit_direct_access:OK
 #547/13  tracing_multi_test/fsession_direct_access:OK
 #547/14  tracing_multi_test/fentry_after_multi:OK
 #547     tracing_multi_test:OK
 Summary: 3/16 PASSED, 0 SKIPPED, 0 FAILED

 ./test_progs -a 'fill_link_info/tracing_multi_*'
 #132/11  fill_link_info/tracing_multi_link_info:OK
 #132/12  fill_link_info/tracing_multi_invalid_ubuff:OK
 #132     fill_link_info:OK
 Summary: 1/2 PASSED, 0 SKIPPED, 0 FAILED

Links:
[1] https://lore.kernel.org/all/20260609-arm64-ftrace-direct-calls-v1-0-4a46f266697f@linux.dev/
[2] https://github.com/kernel-patches/bpf/pull/12986

Leon Hwang (2):
  arm64: ftrace: enable single ftrace_ops for direct calls
  selftests/bpf: Enable tracing_multi tests on arm64

 arch/arm64/Kconfig                                     | 2 ++
 arch/arm64/kernel/ftrace.c                             | 3 +--
 tools/testing/selftests/bpf/prog_tests/tracing_multi.c | 9 +++++++--
 tools/testing/selftests/bpf/test_progs.h               | 6 ++++++
 4 files changed, 16 insertions(+), 4 deletions(-)

-- 
2.55.0

[PATCH 1/2] arm64: ftrace: enable single ftrace_ops for direct calls

[Leon Hwang]

The BPF tracing multi link updates several direct-call sites through one
ftrace_ops. Its implementation is therefore gated by
HAVE_SINGLE_FTRACE_DIRECT_OPS in addition to
DYNAMIC_FTRACE_WITH_DIRECT_CALLS.

Select HAVE_SINGLE_FTRACE_DIRECT_OPS whenever arm64 enables dynamic ftrace
direct calls. This enables BPF tracing multi links on arm64. Also
generalize the unreachable-trampoline comment because the single-ops path
does not use ops->direct_call.

Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
 arch/arm64/Kconfig         | 2 ++
 arch/arm64/kernel/ftrace.c | 3 +--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0de419ed780f..c98dca76859b 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -188,6 +188,8 @@ config ARM64
 		    CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS)
 	select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS \
 		if DYNAMIC_FTRACE_WITH_ARGS
+	select HAVE_SINGLE_FTRACE_DIRECT_OPS \
+		if DYNAMIC_FTRACE_WITH_DIRECT_CALLS
 	select HAVE_DYNAMIC_FTRACE_WITH_CALL_OPS \
 		if (DYNAMIC_FTRACE_WITH_ARGS && !CFI && \
 		    (CC_IS_CLANG || !CC_OPTIMIZE_FOR_SIZE))
diff --git a/arch/arm64/kernel/ftrace.c b/arch/arm64/kernel/ftrace.c
index e1a3c0b3a051..56ba72a87dfa 100644
--- a/arch/arm64/kernel/ftrace.c
+++ b/arch/arm64/kernel/ftrace.c
@@ -301,8 +301,7 @@ static bool ftrace_find_callable_addr(struct dyn_ftrace *rec,
 
 	/*
 	 * If a custom trampoline is unreachable, rely on the ftrace_caller
-	 * trampoline which knows how to indirectly reach that trampoline
-	 * through ops->direct_call.
+	 * trampoline which knows how to indirectly reach that trampoline.
 	 */
 	if (*addr != FTRACE_ADDR && !reachable_by_bl(*addr, pc))
 		*addr = FTRACE_ADDR;
-- 
2.55.0

[PATCH 2/2] selftests/bpf: Enable tracing_multi tests on arm64

[Leon Hwang]

arm64 now supports dynamic ftrace direct calls backed by a single
ftrace_ops, which enables BPF tracing multi links.

Define ARCH_SUPPORTS_TRACING_MULTI_LINK for x86-64 and arm64, and use the
shared capability to gate the tracing_multi functional, rollback,
and attach benchmark tests.

This allows the tests to run on arm64 while continuing to skip
architectures without tracing multi link support. It also prevents the
rollback test from treating an unsupported-link error as its expected
attachment failure.

Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
 tools/testing/selftests/bpf/prog_tests/tracing_multi.c | 9 +++++++--
 tools/testing/selftests/bpf/test_progs.h               | 6 ++++++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/tracing_multi.c b/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
index f02ffc7f41d7..5aa48e090340 100644
--- a/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
+++ b/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
@@ -612,7 +612,7 @@ void serial_test_tracing_multi_bench_attach(void)
 	struct btf *btf;
 	int err;
 
-#ifndef __x86_64__
+#if !ARCH_SUPPORTS_TRACING_MULTI_LINK
 	test__skip();
 	return;
 #endif
@@ -923,6 +923,11 @@ static void test_rollback_unlink(void)
 
 void serial_test_tracing_multi_attach_rollback(void)
 {
+#if !ARCH_SUPPORTS_TRACING_MULTI_LINK
+	test__skip();
+	return;
+#endif
+
 	if (test__start_subtest("put"))
 		test_rollback_put();
 	if (test__start_subtest("unlink"))
@@ -931,7 +936,7 @@ void serial_test_tracing_multi_attach_rollback(void)
 
 void test_tracing_multi_test(void)
 {
-#ifndef __x86_64__
+#if !ARCH_SUPPORTS_TRACING_MULTI_LINK
 	test__skip();
 	return;
 #endif
diff --git a/tools/testing/selftests/bpf/test_progs.h b/tools/testing/selftests/bpf/test_progs.h
index 2cf950afcd85..b1498e84773c 100644
--- a/tools/testing/selftests/bpf/test_progs.h
+++ b/tools/testing/selftests/bpf/test_progs.h
@@ -567,4 +567,10 @@ void validate_msgs(const char *log_buf, struct expected_msgs *msgs,
 void free_msgs(struct expected_msgs *msgs);
 void verify_test_stderr(struct bpf_object *obj, struct bpf_program *prog);
 
+#if defined(__x86_64__) || defined(__aarch64__)
+#define ARCH_SUPPORTS_TRACING_MULTI_LINK 1
+#else
+#define ARCH_SUPPORTS_TRACING_MULTI_LINK 0
+#endif
+
 #endif /* __TEST_PROGS_H */
-- 
2.55.0

Re: [PATCH 1/2] arm64: ftrace: enable single ftrace_ops for direct calls

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Missing RCU read barrier (`rcu_dereference()`) when accessing `direct_functions`.
--

--- Patch [1]: [PATCH 1/2] arm64: ftrace: enable single ftrace_ops for direct calls ---
commit 738274783fa707248af104af5e45da296f7e4d84
Author: Leon Hwang <leon.hwang@linux.dev>

arm64: ftrace: enable single ftrace_ops for direct calls

The BPF tracing multi link updates several direct-call sites through one
ftrace_ops. This commit selects HAVE_SINGLE_FTRACE_DIRECT_OPS on arm64 when
DYNAMIC_FTRACE_WITH_DIRECT_CALLS is enabled. It also generalizes the
unreachable-trampoline comment.

> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 39eba438dad43..94fa6e72c2867 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -188,6 +188,8 @@ config ARM64
>  		    CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_ARGS)
>  	select HAVE_DYNAMIC_FTRACE_WITH_DIRECT_CALLS \
>  		if DYNAMIC_FTRACE_WITH_ARGS
> +	select HAVE_SINGLE_FTRACE_DIRECT_OPS \
> +		if DYNAMIC_FTRACE_WITH_DIRECT_CALLS

[Severity: High]
This is a pre-existing issue, but by enabling HAVE_SINGLE_FTRACE_DIRECT_OPS
on arm64, does this expose the architecture to a missing RCU read barrier
in the ftrace code?

When HAVE_SINGLE_FTRACE_DIRECT_OPS is selected, call_direct_funcs() switches
from using READ_ONCE(ops->direct_call) to using ftrace_find_rec_direct():

kernel/trace/ftrace.c:call_direct_funcs() {
...
#ifdef CONFIG_HAVE_SINGLE_FTRACE_DIRECT_OPS
	addr = ftrace_find_rec_direct(ip);
#else
...
}

Looking at ftrace_find_rec_direct(), it accesses the __rcu pointer
direct_functions directly without an rcu_dereference():

kernel/trace/ftrace.c:ftrace_find_rec_direct() {
	struct ftrace_func_entry *entry;

	entry = __ftrace_lookup_ip(direct_functions, ip);
...
}

Without the READ_ONCE() provided by rcu_dereference(), the compiler might
reload the pointer between computing the hash key and accessing the bucket
array inside __ftrace_lookup_ip().

If a concurrent writer substitutes a new hash table with a different size
between these reloads, could the computed key exceed the new bucket array
bounds and lead to an out-of-bounds dereference?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260727142844.21212-1-leon.hwang@linux.dev?part=1