From: "Emil Tsalapatis" <emil@etsalapatis.com>
To: "Sun Jian" <sun.jian.kdev@gmail.com>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Shuah Khan" <shuah@kernel.org>
Cc: "Eduard Zingerman" <eddyz87@gmail.com>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>, <bpf@vger.kernel.org>,
<linux-kselftest@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably
Date: Sun, 01 Mar 2026 14:59:57 -0500 [thread overview]
Message-ID: <DGRPNT4T4EJP.1USTJ2K0RETA3@etsalapatis.com> (raw)
In-Reply-To: <20260227164037.84110-3-sun.jian.kdev@gmail.com>
On Fri Feb 27, 2026 at 11:40 AM EST, Sun Jian wrote:
> The perf_event subtest relies on SW_CPU_CLOCK sampling to trigger the BPF
> program, but the current CPU burn loop can be too short on slower systems
> and may fail to generate any overflow sample. This leaves pe_res unchanged
> and makes the test flaky.
>
> Make burn_cpu() take a loop count and use a longer burn only for the
> perf_event subtest. Also scope perf_event_open() to the current task to
> avoid wasting samples on unrelated activity.
>
> Tested:
> ./test_progs -t bpf_cookie/perf_event -vv (30 runs): 0 failures
>
> Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
Reviewed-by: Emil Tsalapatis <emil@etsalapatis.com>
Nit below, but change makes sense.
> ---
> .../selftests/bpf/prog_tests/bpf_cookie.c | 17 ++++++++++-------
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> index 50f5e11e6e65..35adc3f6d443 100644
> --- a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> @@ -6,6 +6,7 @@
> #include <sys/syscall.h>
> #include <sys/mman.h>
> #include <unistd.h>
> +#include <linux/compiler.h>
> #include <test_progs.h>
> #include <network_helpers.h>
> #include <bpf/btf.h>
> @@ -431,11 +432,12 @@ static void tp_subtest(struct test_bpf_cookie *skel)
> bpf_link__destroy(link3);
> }
>
> -static void burn_cpu(void)
> +static void burn_cpu(long loops)
> {
> - volatile int j = 0;
> + long j = 0;
Nit: AFAICT most of these changes are unnecessary, you could just bump
the cycle count to 100M and add the barrier. Moving everything to longs
and factoring out the loop count is unnecessary.
> cpu_set_t cpu_set;
> - int i, err;
> + long i;
> + int err;
>
> /* generate some branches on cpu 0 */
> CPU_ZERO(&cpu_set);
> @@ -443,9 +445,10 @@ static void burn_cpu(void)
> err = pthread_setaffinity_np(pthread_self(), sizeof(cpu_set), &cpu_set);
> ASSERT_OK(err, "set_thread_affinity");
>
> - /* spin the loop for a while (random high number) */
> - for (i = 0; i < 1000000; ++i)
> + for (i = 0; i < loops; ++i) {
> ++j;
> + barrier();
> + }
> }
>
> static void pe_subtest(struct test_bpf_cookie *skel)
> @@ -470,7 +473,7 @@ static void pe_subtest(struct test_bpf_cookie *skel)
> if (!ASSERT_OK_PTR(link, "link1"))
> goto cleanup;
>
> - burn_cpu(); /* trigger BPF prog */
> + burn_cpu(100000000L); /* trigger BPF prog */
>
> ASSERT_EQ(skel->bss->pe_res, 0x100000, "pe_res1");
>
> @@ -489,7 +492,7 @@ static void pe_subtest(struct test_bpf_cookie *skel)
> if (!ASSERT_OK_PTR(link, "link2"))
> goto cleanup;
>
> - burn_cpu(); /* trigger BPF prog */
> + burn_cpu(100000000L); /* trigger BPF prog */
>
> ASSERT_EQ(skel->bss->pe_res, 0x200000, "pe_res2");
>
next prev parent reply other threads:[~2026-03-01 19:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-27 16:40 [PATCH 0/2] selftests/bpf: fix bpf_cookie failures Sun Jian
2026-02-27 16:40 ` [PATCH 1/2] selftests/bpf: bpf_cookie: skip kprobe_multi tests without bpf_testmod Sun Jian
2026-02-27 18:18 ` Alexei Starovoitov
2026-02-28 2:58 ` sun jian
2026-02-27 16:40 ` [PATCH 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably Sun Jian
2026-02-27 17:16 ` bot+bpf-ci
2026-03-01 19:59 ` Emil Tsalapatis [this message]
2026-03-02 2:24 ` sun jian
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=DGRPNT4T4EJP.1USTJ2K0RETA3@etsalapatis.com \
--to=emil@etsalapatis.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=shuah@kernel.org \
--cc=sun.jian.kdev@gmail.com \
/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