BPF List
 help / color / mirror / Atom feed
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)
> 


      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