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 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.