[PATCH bpf-next 0/2] bpf: Fix WARNING in bpf_trampoline_multi_detach

[PATCH bpf-next 0/2] bpf: Fix WARNING in bpf_trampoline_multi_detach

[Leon Hwang]

Since tracing_multi link does not set ftrace_managed, it would fail to
release the tracing_multi link when attaching tracing_multi link and
then attaching fentry link.

[    3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97
...
[    3.733170]  bpf_tracing_multi_link_release+0x14/0x30
[    3.733890]  bpf_link_free+0x58/0x130
[    3.734414]  bpf_link_release+0x23/0x30

Fix it by setting 'ftrace_managed = true' in register_fentry_multi().

Note: the reason of targeting bpf-next tree is I'm planning to add
tracing_multi link support for bpf progs, that would rely on the fix and
have code conflict with the test.

Leon Hwang (2):
  bpf: Mark tracing_multi trampolines as ftrace managed
  selftests/bpf: Test fentry link after tracing_multi link

 kernel/bpf/trampoline.c                       |  1 +
 .../selftests/bpf/prog_tests/tracing_multi.c  | 69 +++++++++++++++++++
 .../progs/tracing_multi_intersect_attach.c    |  8 +++
 3 files changed, 78 insertions(+)

-- 
2.55.0

[PATCH bpf-next 1/2] bpf: Mark tracing_multi trampolines as ftrace managed

[Leon Hwang]

Since tracing_multi link does not set ftrace_managed, it would fail to
release the tracing_multi link when attaching tracing_multi link and
then attaching fentry link.

[    3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97
...
[    3.733170]  bpf_tracing_multi_link_release+0x14/0x30
[    3.733890]  bpf_link_free+0x58/0x130
[    3.734414]  bpf_link_release+0x23/0x30

Fix it by setting 'ftrace_managed = true' in register_fentry_multi().

Fixes: aef4dfa790b2 ("bpf: Add bpf_trampoline_multi_attach/detach functions")
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
 kernel/bpf/trampoline.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
index 1a721fc4bef5..6eadf64f7ec9 100644
--- a/kernel/bpf/trampoline.c
+++ b/kernel/bpf/trampoline.c
@@ -1536,6 +1536,7 @@ static int register_fentry_multi(struct bpf_trampoline *tr, struct bpf_tramp_ima
 	if (bpf_trampoline_use_jmp(tr->flags))
 		addr = ftrace_jmp_set(addr);
 
+	tr->func.ftrace_managed = true;
 	ftrace_hash_add(data->reg, data->entry, ip, addr);
 	tr->cur_image = im;
 	return 0;
-- 
2.55.0

Re: [PATCH bpf-next 1/2] bpf: Mark tracing_multi trampolines as ftrace managed

[Jiri Olsa]

On Fri, Jul 10, 2026 at 10:47:33PM +0800, Leon Hwang wrote:
> Since tracing_multi link does not set ftrace_managed, it would fail to
> release the tracing_multi link when attaching tracing_multi link and
> then attaching fentry link.
> 
> [    3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97
> ...
> [    3.733170]  bpf_tracing_multi_link_release+0x14/0x30
> [    3.733890]  bpf_link_free+0x58/0x130
> [    3.734414]  bpf_link_release+0x23/0x30
> 
> Fix it by setting 'ftrace_managed = true' in register_fentry_multi().
> 
> Fixes: aef4dfa790b2 ("bpf: Add bpf_trampoline_multi_attach/detach functions")
> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
> ---
>  kernel/bpf/trampoline.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
> index 1a721fc4bef5..6eadf64f7ec9 100644
> --- a/kernel/bpf/trampoline.c
> +++ b/kernel/bpf/trampoline.c
> @@ -1536,6 +1536,7 @@ static int register_fentry_multi(struct bpf_trampoline *tr, struct bpf_tramp_ima
>  	if (bpf_trampoline_use_jmp(tr->flags))
>  		addr = ftrace_jmp_set(addr);
>  
> +	tr->func.ftrace_managed = true;

I wonder we could set tr->func.ftrace_managed early in bpf_trampoline_get,
but we could do that as follow up

Acked-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka


>  	ftrace_hash_add(data->reg, data->entry, ip, addr);
>  	tr->cur_image = im;
>  	return 0;
> -- 
> 2.55.0
> 

Re: [PATCH bpf-next 1/2] bpf: Mark tracing_multi trampolines as ftrace managed

[Leon Hwang]

On 2026/7/11 06:15, Jiri Olsa wrote:
> On Fri, Jul 10, 2026 at 10:47:33PM +0800, Leon Hwang wrote:
>> Since tracing_multi link does not set ftrace_managed, it would fail to
>> release the tracing_multi link when attaching tracing_multi link and
>> then attaching fentry link.
>>
>> [    3.714215] WARNING: kernel/bpf/trampoline.c:1727 at bpf_trampoline_multi_detach+0x20b/0x240, CPU#1: test_progs/97
>> ...
>> [    3.733170]  bpf_tracing_multi_link_release+0x14/0x30
>> [    3.733890]  bpf_link_free+0x58/0x130
>> [    3.734414]  bpf_link_release+0x23/0x30
>>
>> Fix it by setting 'ftrace_managed = true' in register_fentry_multi().
>>
>> Fixes: aef4dfa790b2 ("bpf: Add bpf_trampoline_multi_attach/detach functions")
>> Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
>> ---
>>  kernel/bpf/trampoline.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/kernel/bpf/trampoline.c b/kernel/bpf/trampoline.c
>> index 1a721fc4bef5..6eadf64f7ec9 100644
>> --- a/kernel/bpf/trampoline.c
>> +++ b/kernel/bpf/trampoline.c
>> @@ -1536,6 +1536,7 @@ static int register_fentry_multi(struct bpf_trampoline *tr, struct bpf_tramp_ima
>>  	if (bpf_trampoline_use_jmp(tr->flags))
>>  		addr = ftrace_jmp_set(addr);
>>  
>> +	tr->func.ftrace_managed = true;
> 
> I wonder we could set tr->func.ftrace_managed early in bpf_trampoline_get,
> but we could do that as follow up


Makes sense. Let me try it when adding tracing_multi link support for
bpf progs.

> 
> Acked-by: Jiri Olsa <jolsa@kernel.org>


Thanks for your review.

Leon

> 
> thanks,
> jirka
> 
> 
>>  	ftrace_hash_add(data->reg, data->entry, ip, addr);
>>  	tr->cur_image = im;
>>  	return 0;
>> -- 
>> 2.55.0
>>

[PATCH bpf-next 2/2] selftests/bpf: Test fentry link after tracing_multi link

[Leon Hwang]

Verify that there's no any issue to attach tracing_multi link, then attach
fentry link.

Assisted-by: Codex:gpt-5.6-sol
Signed-off-by: Leon Hwang <leon.hwang@linux.dev>
---
 .../selftests/bpf/prog_tests/tracing_multi.c  | 69 +++++++++++++++++++
 .../progs/tracing_multi_intersect_attach.c    |  8 +++
 2 files changed, 77 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/tracing_multi.c b/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
index f02ffc7f41d7..0aa9532a05cf 100644
--- a/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
+++ b/tools/testing/selftests/bpf/prog_tests/tracing_multi.c
@@ -460,6 +460,73 @@ static void test_intersect(void)
 	tracing_multi_intersect__destroy(skel);
 }
 
+static void test_fentry_after_multi(void)
+{
+	static const char * const funcs[] = {
+		"bpf_fentry_test1",
+	};
+	struct bpf_link *fentry_link = NULL, *multi_link = NULL;
+	struct tracing_multi_intersect *skel = NULL;
+	LIBBPF_OPTS(bpf_tracing_multi_opts, opts);
+	LIBBPF_OPTS(bpf_test_run_opts, topts);
+	__u32 *ids = NULL;
+	int err;
+
+	skel = tracing_multi_intersect__open_and_load();
+	if (!ASSERT_OK_PTR(skel, "tracing_multi_intersect__open_and_load"))
+		return;
+
+	skel->bss->pid = getpid();
+
+	ids = get_ids(funcs, ARRAY_SIZE(funcs), NULL);
+	if (!ASSERT_OK_PTR(ids, "get_ids"))
+		goto cleanup;
+
+	opts.ids = ids;
+	opts.cnt = ARRAY_SIZE(funcs);
+	multi_link = bpf_program__attach_tracing_multi(skel->progs.fentry_1, NULL, &opts);
+	if (!ASSERT_OK_PTR(multi_link, "attach_multi"))
+		goto cleanup;
+
+	fentry_link = bpf_program__attach(skel->progs.fentry);
+	if (!ASSERT_OK_PTR(fentry_link, "attach_fentry"))
+		goto cleanup;
+
+	err = bpf_prog_test_run_opts(bpf_program__fd(skel->progs.fentry_1), &topts);
+	if (!ASSERT_OK(err, "test_run"))
+		goto cleanup;
+	ASSERT_EQ(skel->bss->test_result_fentry_1, 1, "multi_fentry");
+	ASSERT_EQ(skel->bss->test_result_fentry, 1, "fentry");
+
+	err = bpf_link__destroy(fentry_link);
+	fentry_link = NULL;
+	if (!ASSERT_OK(err, "destroy_fentry"))
+		goto cleanup;
+
+	err = bpf_prog_test_run_opts(bpf_program__fd(skel->progs.fentry_1), &topts);
+	if (!ASSERT_OK(err, "test_run_multi"))
+		goto cleanup;
+	ASSERT_EQ(skel->bss->test_result_fentry_1, 2, "multi_fentry_only");
+	ASSERT_EQ(skel->bss->test_result_fentry, 1, "fentry_detached");
+
+	err = bpf_link__destroy(multi_link);
+	multi_link = NULL;
+	if (!ASSERT_OK(err, "destroy_multi"))
+		goto cleanup;
+
+	err = bpf_prog_test_run_opts(bpf_program__fd(skel->progs.fentry_1), &topts);
+	if (!ASSERT_OK(err, "test_run_detached"))
+		goto cleanup;
+	ASSERT_EQ(skel->bss->test_result_fentry_1, 2, "multi_fentry_detached");
+	ASSERT_EQ(skel->bss->test_result_fentry, 1, "fentry_still_detached");
+
+cleanup:
+	bpf_link__destroy(fentry_link);
+	bpf_link__destroy(multi_link);
+	free(ids);
+	tracing_multi_intersect__destroy(skel);
+}
+
 static void test_session(void)
 {
 	LIBBPF_OPTS(bpf_test_run_opts, topts);
@@ -957,4 +1024,6 @@ void test_tracing_multi_test(void)
 	if (test__start_subtest("attach_api_fails"))
 		test_attach_api_fails();
 	RUN_TESTS(tracing_multi_verifier);
+	if (test__start_subtest("fentry_after_multi"))
+		test_fentry_after_multi();
 }
diff --git a/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c b/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c
index cd5be0bb6ffd..5ebbe3b602a4 100644
--- a/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c
+++ b/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c
@@ -11,6 +11,14 @@ __u64 test_result_fentry_1 = 0;
 __u64 test_result_fentry_2 = 0;
 __u64 test_result_fexit_1 = 0;
 __u64 test_result_fexit_2 = 0;
+__u64 test_result_fentry = 0;
+
+SEC("fentry/bpf_fentry_test1")
+int BPF_PROG(fentry, int a)
+{
+	test_result_fentry += a == 1;
+	return 0;
+}
 
 SEC("fentry.multi")
 int BPF_PROG(fentry_1)
-- 
2.55.0

Re: [PATCH bpf-next 2/2] selftests/bpf: Test fentry link after tracing_multi link

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] Test Flakiness due to Missing PID Filtering in BPF `fentry` Program
--

--- Patch [2]: [PATCH bpf-next 2/2] selftests/bpf: Test fentry link after tracing_multi link ---
commit 7dc95a7a3d3a0ca96e45e5ad2ebebe5157ae17ed
Author: Leon Hwang <leon.hwang@linux.dev>

selftests/bpf: Test fentry link after tracing_multi link

This commit adds a selftest to verify that an fentry link can be attached
safely after a tracing_multi link. It introduces a new fentry BPF program
and a corresponding user-space test case.

> diff --git a/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c b/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c
> index cd5be0bb6ffdd..5ebbe3b602a4f 100644
> --- a/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c
> +++ b/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c

[ ... ]

> @@ -11,6 +11,14 @@ __u64 test_result_fentry_1 = 0;
>  __u64 test_result_fentry_2 = 0;
>  __u64 test_result_fexit_1 = 0;
>  __u64 test_result_fexit_2 = 0;
> +__u64 test_result_fentry = 0;
> +
> +SEC("fentry/bpf_fentry_test1")
> +int BPF_PROG(fentry, int a)
> +{
> +	test_result_fentry += a == 1;

[Severity: Medium]
Can this cause test flakiness during parallel selftest runs?

Because bpf_fentry_test1 is a global kernel function widely used across
various BPF selftests, parallel test executions might trigger this program.
Since the counter is incremented blindly without filtering by the executing
process PID, could parallel executions increase test_result_fentry above 1
and cause the userland assertion ASSERT_EQ(skel->bss->test_result_fentry, 1)
to sporadically fail?

> +	return 0;
> +}
>  
>  SEC("fentry.multi")
>  int BPF_PROG(fentry_1)

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

Re: [PATCH bpf-next 2/2] selftests/bpf: Test fentry link after tracing_multi link

[Leon Hwang]

On 2026/7/10 23:04, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] Test Flakiness due to Missing PID Filtering in BPF `fentry` Program
> --
> 
> --- Patch [2]: [PATCH bpf-next 2/2] selftests/bpf: Test fentry link after tracing_multi link ---
> commit 7dc95a7a3d3a0ca96e45e5ad2ebebe5157ae17ed
> Author: Leon Hwang <leon.hwang@linux.dev>
> 
> selftests/bpf: Test fentry link after tracing_multi link
> 
> This commit adds a selftest to verify that an fentry link can be attached
> safely after a tracing_multi link. It introduces a new fentry BPF program
> and a corresponding user-space test case.
> 
>> diff --git a/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c b/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c
>> index cd5be0bb6ffdd..5ebbe3b602a4f 100644
>> --- a/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c
>> +++ b/tools/testing/selftests/bpf/progs/tracing_multi_intersect_attach.c
> 
> [ ... ]
> 
>> @@ -11,6 +11,14 @@ __u64 test_result_fentry_1 = 0;
>>  __u64 test_result_fentry_2 = 0;
>>  __u64 test_result_fexit_1 = 0;
>>  __u64 test_result_fexit_2 = 0;
>> +__u64 test_result_fentry = 0;
>> +
>> +SEC("fentry/bpf_fentry_test1")
>> +int BPF_PROG(fentry, int a)
>> +{
>> +	test_result_fentry += a == 1;
> 
> [Severity: Medium]
> Can this cause test flakiness during parallel selftest runs?
> 
> Because bpf_fentry_test1 is a global kernel function widely used across
> various BPF selftests, parallel test executions might trigger this program.
> Since the counter is incremented blindly without filtering by the executing
> process PID, could parallel executions increase test_result_fentry above 1
> and cause the userland assertion ASSERT_EQ(skel->bss->test_result_fentry, 1)
> to sporadically fail?
> 


Correct.

I should use tracing_multi_arg_check() here, which would filter the PID.

Thanks,
Leon

>> +	return 0;
>> +}
>>  
>>  SEC("fentry.multi")
>>  int BPF_PROG(fentry_1)
>