From: Leon Hwang <leon.hwang@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next 2/2] selftests/bpf: Test fentry link after tracing_multi link
Date: Fri, 10 Jul 2026 23:14:55 +0800 [thread overview]
Message-ID: <49cc5acf-24d4-4e1a-86a0-d05e29a75d42@linux.dev> (raw)
In-Reply-To: <20260710150412.5E8981F000E9@smtp.kernel.org>
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)
>
prev parent reply other threads:[~2026-07-10 15:15 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-10 14:47 [PATCH bpf-next 0/2] bpf: Fix WARNING in bpf_trampoline_multi_detach Leon Hwang
2026-07-10 14:47 ` [PATCH bpf-next 1/2] bpf: Mark tracing_multi trampolines as ftrace managed Leon Hwang
2026-07-10 22:15 ` Jiri Olsa
2026-07-11 12:09 ` Leon Hwang
2026-07-10 14:47 ` [PATCH bpf-next 2/2] selftests/bpf: Test fentry link after tracing_multi link Leon Hwang
2026-07-10 15:04 ` sashiko-bot
2026-07-10 15:14 ` Leon Hwang [this message]
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=49cc5acf-24d4-4e1a-86a0-d05e29a75d42@linux.dev \
--to=leon.hwang@linux.dev \
--cc=bpf@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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