[PATCH v2 0/2] selftests/bpf: fix bpf_cookie failures

[PATCH v2 0/2] selftests/bpf: fix bpf_cookie failures

[Sun Jian]

Fix bpf_cookie failures due to missing bpf_testmod and flaky perf_event
triggering.

Tested:
  ./test_progs -t bpf_cookie/perf_event -vv (30 runs): 0 failures
  ./test_progs -t bpf_cookie -vv

Sun Jian (2):
  selftests/bpf: bpf_cookie: skip kprobe_multi tests without bpf_testmod
  selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably

 .../selftests/bpf/prog_tests/bpf_cookie.c     | 29 ++++++++++++++-----
 1 file changed, 21 insertions(+), 8 deletions(-)


base-commit: f4d0ec0aa20d49f09dc01d82894ce80d72de0560
-- 
2.43.0

[PATCH v2 1/2] selftests/bpf: bpf_cookie: skip kprobe_multi tests without bpf_testmod

[Sun Jian]

The kprobe_multi subtests rely on bpf_testmod fentry ksyms.

When bpf_testmod isn't available, libbpf fails to resolve
bpf_testmod_fentry_test* and skeleton load fails with -ESRCH, causing
false failures.

Skip these subtests when env.has_testmod is false.

Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>

---
Changes in v2:

No functional change.

Drop the unrelated perf_event_open() argument change from this patch
(moved to patch 2/2).

v1: <https://lore.kernel.org/lkml/20260227164037.84110-1-sun.jian.kdev@gmail.com/>
---
 tools/testing/selftests/bpf/prog_tests/bpf_cookie.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
index 75f4dff7d042..b7643a5bf7ad 100644
--- a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
+++ b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
@@ -105,6 +105,11 @@ static void kprobe_multi_link_api_subtest(void)
 	unsigned long long addrs[8];
 	__u64 cookies[8];
 
+	if (!env.has_testmod) {
+		test__skip();
+		return;
+	}
+
 	if (!ASSERT_OK(load_kallsyms(), "load_kallsyms"))
 		goto cleanup;
 
@@ -192,6 +197,11 @@ static void kprobe_multi_attach_api_subtest(void)
 	};
 	__u64 cookies[8];
 
+	if (!env.has_testmod) {
+		test__skip();
+		return;
+	}
+
 	skel = kprobe_multi__open_and_load();
 	if (!ASSERT_OK_PTR(skel, "fentry_raw_skel_load"))
 		goto cleanup;
-- 
2.43.0

Re: [PATCH v2 1/2] selftests/bpf: bpf_cookie: skip kprobe_multi tests without bpf_testmod

[Jiri Olsa]

On Sat, Feb 28, 2026 at 03:45:54PM +0800, Sun Jian wrote:
> The kprobe_multi subtests rely on bpf_testmod fentry ksyms.
> 
> When bpf_testmod isn't available, libbpf fails to resolve
> bpf_testmod_fentry_test* and skeleton load fails with -ESRCH, causing
> false failures.
> 
> Skip these subtests when env.has_testmod is false.
> 
> Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>

please include bpf-next in the subject, other than that:

Acked-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka

> 
> ---
> Changes in v2:
> 
> No functional change.
> 
> Drop the unrelated perf_event_open() argument change from this patch
> (moved to patch 2/2).
> 
> v1: <https://lore.kernel.org/lkml/20260227164037.84110-1-sun.jian.kdev@gmail.com/>
> ---
>  tools/testing/selftests/bpf/prog_tests/bpf_cookie.c | 10 ++++++++++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> index 75f4dff7d042..b7643a5bf7ad 100644
> --- a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> +++ b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> @@ -105,6 +105,11 @@ static void kprobe_multi_link_api_subtest(void)
>  	unsigned long long addrs[8];
>  	__u64 cookies[8];
>  
> +	if (!env.has_testmod) {
> +		test__skip();
> +		return;
> +	}
> +
>  	if (!ASSERT_OK(load_kallsyms(), "load_kallsyms"))
>  		goto cleanup;
>  
> @@ -192,6 +197,11 @@ static void kprobe_multi_attach_api_subtest(void)
>  	};
>  	__u64 cookies[8];
>  
> +	if (!env.has_testmod) {
> +		test__skip();
> +		return;
> +	}
> +
>  	skel = kprobe_multi__open_and_load();
>  	if (!ASSERT_OK_PTR(skel, "fentry_raw_skel_load"))
>  		goto cleanup;
> -- 
> 2.43.0
> 
> 

[PATCH v2 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably

[Sun Jian]

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.

Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>

---
Changes in v2:

Move the perf_event_open() argument change here from patch 1/2.

v1: <https://lore.kernel.org/lkml/20260227164037.84110-1-sun.jian.kdev@gmail.com/>
---
 .../selftests/bpf/prog_tests/bpf_cookie.c     | 19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
index b7643a5bf7ad..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;
 	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)
@@ -461,7 +464,7 @@ static void pe_subtest(struct test_bpf_cookie *skel)
 	attr.type = PERF_TYPE_SOFTWARE;
 	attr.config = PERF_COUNT_SW_CPU_CLOCK;
 	attr.sample_period = 100000;
-	pfd = syscall(__NR_perf_event_open, &attr, -1, 0, -1, PERF_FLAG_FD_CLOEXEC);
+	pfd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, PERF_FLAG_FD_CLOEXEC);
 	if (!ASSERT_GE(pfd, 0, "perf_fd"))
 		goto cleanup;
 
@@ -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");
 
-- 
2.43.0

Re: [PATCH v2 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably

[Jiri Olsa]

On Sat, Feb 28, 2026 at 03:45:55PM +0800, 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.
> 
> Signed-off-by: Sun Jian <sun.jian.kdev@gmail.com>
> 
> ---
> Changes in v2:
> 
> Move the perf_event_open() argument change here from patch 1/2.
> 
> v1: <https://lore.kernel.org/lkml/20260227164037.84110-1-sun.jian.kdev@gmail.com/>
> ---
>  .../selftests/bpf/prog_tests/bpf_cookie.c     | 19 +++++++++++--------
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c b/tools/testing/selftests/bpf/prog_tests/bpf_cookie.c
> index b7643a5bf7ad..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)

nit, there's another burn_cpu in prog_tests/perf_link.c,
we could add it to trace_helpers.c or test_progs.c 

>  {
> -	volatile int j = 0;
> +	long j = 0;
>  	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();

what's the rationale for barrier call in here,
together with the volatile change above?

thanks,
jirka


> +	}
>  }
>  
>  static void pe_subtest(struct test_bpf_cookie *skel)
> @@ -461,7 +464,7 @@ static void pe_subtest(struct test_bpf_cookie *skel)
>  	attr.type = PERF_TYPE_SOFTWARE;
>  	attr.config = PERF_COUNT_SW_CPU_CLOCK;
>  	attr.sample_period = 100000;
> -	pfd = syscall(__NR_perf_event_open, &attr, -1, 0, -1, PERF_FLAG_FD_CLOEXEC);
> +	pfd = syscall(__NR_perf_event_open, &attr, 0, -1, -1, PERF_FLAG_FD_CLOEXEC);
>  	if (!ASSERT_GE(pfd, 0, "perf_fd"))
>  		goto cleanup;
>  
> @@ -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");
>  
> -- 
> 2.43.0
> 
> 

Re: [PATCH v2 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably

[sun jian]

On Mon, Mar 2, 2026 at 6:02 PM Jiri Olsa <olsajiri@gmail.com> wrote:
>
> On Sat, Feb 28, 2026 at 03:45:55PM +0800, Sun Jian wrote:
> > The perf_event subtest relies on SW_CPU_CLOCK sampling to trigger the BPF
> > -static void burn_cpu(void)
> > +static void burn_cpu(long loops)
>
> nit, there's another burn_cpu in prog_tests/perf_link.c,
> we could add it to trace_helpers.c or test_progs.c
>

happy to refactor into a shared helper if maintainers prefer, but I keep it
local to minimize the diff.

> >  {
> > -     volatile int j = 0;
> > +     long j = 0;
> >       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();
>
> what's the rationale for barrier call in here,
> together with the volatile change above?
>

The burn_cpu() loop is only meant to consume CPU time to reliably trigger the
SW_CPU_CLOCK perf_event overflow. With an side-effect-free loop, the
compiler may optimize the loop away or significantly shrink it under -O2.

The old version relied on volatile to prevent the loop from being optimized, but
checkpatch warns against it. Using barrier() achieves the same goal  — keep the
loop intact as a CPU-burn  — while making the intent more explicit.

Thanks,
Sun Jian

Re: [PATCH v2 2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably

[Jiri Olsa]

On Tue, Mar 03, 2026 at 10:15:26AM +0800, sun jian wrote:
> On Mon, Mar 2, 2026 at 6:02 PM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Sat, Feb 28, 2026 at 03:45:55PM +0800, Sun Jian wrote:
> > > The perf_event subtest relies on SW_CPU_CLOCK sampling to trigger the BPF
> > > -static void burn_cpu(void)
> > > +static void burn_cpu(long loops)
> >
> > nit, there's another burn_cpu in prog_tests/perf_link.c,
> > we could add it to trace_helpers.c or test_progs.c
> >
> 
> happy to refactor into a shared helper if maintainers prefer, but I keep it
> local to minimize the diff.
> 
> > >  {
> > > -     volatile int j = 0;
> > > +     long j = 0;
> > >       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();
> >
> > what's the rationale for barrier call in here,
> > together with the volatile change above?
> >
> 
> The burn_cpu() loop is only meant to consume CPU time to reliably trigger the
> SW_CPU_CLOCK perf_event overflow. With an side-effect-free loop, the
> compiler may optimize the loop away or significantly shrink it under -O2.
> 
> The old version relied on volatile to prevent the loop from being optimized, but
> checkpatch warns against it. Using barrier() achieves the same goal  — keep the
> loop intact as a CPU-burn  — while making the intent more explicit.

ok, would be great to have this in the changelog, other than that:

Acked-by: Jiri Olsa <jolsa@kernel.org>

thanks,
jirka

Re: [PATCH v2 0/2] selftests/bpf: fix bpf_cookie failures

[patchwork-bot+netdevbpf]

Hello:

This series was applied to bpf/bpf-next.git (master)
by Andrii Nakryiko <andrii@kernel.org>:

On Sat, 28 Feb 2026 15:45:53 +0800 you wrote:
> Fix bpf_cookie failures due to missing bpf_testmod and flaky perf_event
> triggering.
> 
> Tested:
>   ./test_progs -t bpf_cookie/perf_event -vv (30 runs): 0 failures
>   ./test_progs -t bpf_cookie -vv
> 
> [...]

Here is the summary with links:
  - [v2,1/2] selftests/bpf: bpf_cookie: skip kprobe_multi tests without bpf_testmod
    https://git.kernel.org/bpf/bpf-next/c/74d3305e620b
  - [v2,2/2] selftests/bpf: bpf_cookie: make perf_event subtest trigger reliably
    https://git.kernel.org/bpf/bpf-next/c/7f20d371fd87

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html