public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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");
>  


  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