[PATCH bpf-next 1/2] selftests/bpf: Move verifier failure tests out of test_global_percpu_data

[PATCH bpf-next 1/2] selftests/bpf: Move verifier failure tests out of test_global_percpu_data

[Thiébaud Weksteen]

Commit 4c9241bd731a ("selftests/bpf: Add tests to verify global percpu
data") added test_global_percpu_data.c to LSKELS_EXTRA. Later, in commit
1ed2294b31fc ("selftests/bpf: Test verifier log for global percpu data")
two verifier failure tests were added (verifier_strncmp and
verifier_snprintf), both marked as non-autoload (SEC("?kprobe")).

When bpftool generates light skeletons, non-autoloaded programs are
skipped during loading, causing the loader program to store subsequent
program FDs into incorrect skeleton struct fields (e.g. dump_percpu_data's
FD was stored into verifier_strncmp's descriptor).

Move the two verifier failure tests to a dedicated test file,
test_global_percpu_data_failure.c, and run them via RUN_TESTS in
global_data_init.c. This leaves test_global_percpu_data.c with only
autoloaded programs, ensuring the light skeleton can be generated cleanly
and correctly.

Fixes: 4c9241bd731a ("selftests/bpf: Add tests to verify global percpu data")
Fixes: 1ed2294b31fc ("selftests/bpf: Test verifier log for global percpu data")
Signed-off-by: Thiébaud Weksteen <tweek@google.com>
---
 .../bpf/prog_tests/global_data_init.c         |  3 +-
 .../bpf/progs/test_global_percpu_data.c       | 23 --------------
 .../progs/test_global_percpu_data_failure.c   | 30 +++++++++++++++++++
 3 files changed, 32 insertions(+), 24 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/test_global_percpu_data_failure.c

diff --git a/tools/testing/selftests/bpf/prog_tests/global_data_init.c b/tools/testing/selftests/bpf/prog_tests/global_data_init.c
index 7c539cbcf3a1..dbb7de534f7d 100644
--- a/tools/testing/selftests/bpf/prog_tests/global_data_init.c
+++ b/tools/testing/selftests/bpf/prog_tests/global_data_init.c
@@ -3,6 +3,7 @@
 #include "bpf/libbpf_internal.h"
 #include "test_global_percpu_data.skel.h"
 #include "test_global_percpu_data.lskel.h"
+#include "test_global_percpu_data_failure.skel.h"
 
 void test_global_data_init(void)
 {
@@ -372,7 +373,7 @@ static void test_global_percpu_data_rdonly_direct_write(void)
 
 static void test_global_percpu_data_verifier_log(void)
 {
-	RUN_TESTS(test_global_percpu_data);
+	RUN_TESTS(test_global_percpu_data_failure);
 }
 
 static void test_global_percpu_data_iter(void)
diff --git a/tools/testing/selftests/bpf/progs/test_global_percpu_data.c b/tools/testing/selftests/bpf/progs/test_global_percpu_data.c
index 2765cd46e9af..bc748df4a6cc 100644
--- a/tools/testing/selftests/bpf/progs/test_global_percpu_data.c
+++ b/tools/testing/selftests/bpf/progs/test_global_percpu_data.c
@@ -42,29 +42,6 @@ int update_percpu_data(void *ctx)
 	return 0;
 }
 
-static const char fmt[] SEC(".percpu.fmt") = "data %d\n";
-
-SEC("?kprobe")
-__failure __msg("R{{[0-9]+}} points to percpu_array map which cannot be used as const string")
-int verifier_strncmp(void *ctx)
-{
-	return bpf_strncmp("test", 5, fmt);
-}
-
-SEC("?kprobe")
-__failure __msg("R{{[0-9]+}} points to percpu_array map which cannot be used as const string")
-int verifier_snprintf(void *ctx)
-{
-	u64 args[] = { data };
-	char buf[128];
-	int len;
-
-	len = bpf_snprintf(buf, sizeof(buf), fmt, args, sizeof(args));
-	if (len > 0)
-		bpf_printk("snprintf: %s\n", buf);
-	return 0;
-}
-
 volatile const __u32 num_cpus = 0;
 volatile const int num_off;
 volatile const int elem_sz;
diff --git a/tools/testing/selftests/bpf/progs/test_global_percpu_data_failure.c b/tools/testing/selftests/bpf/progs/test_global_percpu_data_failure.c
new file mode 100644
index 000000000000..3a823acb42d7
--- /dev/null
+++ b/tools/testing/selftests/bpf/progs/test_global_percpu_data_failure.c
@@ -0,0 +1,30 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <vmlinux.h>
+#include <bpf/bpf_helpers.h>
+#include "bpf_misc.h"
+
+int data SEC(".percpu") = -1;
+static const char fmt[] SEC(".percpu.fmt") = "data %d\n";
+
+SEC("?kprobe")
+__failure __msg("R{{[0-9]+}} points to percpu_array map which cannot be used as const string")
+int verifier_strncmp(void *ctx)
+{
+	return bpf_strncmp("test", 5, fmt);
+}
+
+SEC("?kprobe")
+__failure __msg("R{{[0-9]+}} points to percpu_array map which cannot be used as const string")
+int verifier_snprintf(void *ctx)
+{
+	u64 args[] = { data };
+	char buf[128];
+	int len;
+
+	len = bpf_snprintf(buf, sizeof(buf), fmt, args, sizeof(args));
+	if (len > 0)
+		bpf_printk("snprintf: %s\n", buf);
+	return 0;
+}
+
+char _license[] SEC("license") = "GPL";
-- 
2.55.0.979.g7e5102b832-goog

[PATCH bpf-next 2/2] bpftool: Reject non-autoload programs for light skeletons

[Thiébaud Weksteen]

When generating a light skeleton (bpftool gen skeleton -L), there is no
libbpf runtime object or bpf_program__set_autoload() API available to
enable/disable the autoloading of programs. If a BPF program in the
object has autoload disabled (e.g. via SEC("?...")), bpf_object__load()
silently skips loading it. bpftool still generates struct bpf_prog_desc
fields and attach functions in the light skeleton header, leaving
skel->progs.<name>.prog_fd uninitialized (0).

Explicitly reject non-autoloaded programs when use_loader is true with
an error message, preventing the generation of broken light skeleton
headers.

Signed-off-by: Thiébaud Weksteen <tweek@google.com>
---
 tools/bpf/bpftool/gen.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
index a50540ef6521..1583150241c8 100644
--- a/tools/bpf/bpftool/gen.c
+++ b/tools/bpf/bpftool/gen.c
@@ -1340,6 +1340,12 @@ static int do_skeleton(int argc, char **argv)
 	}
 	bpf_object__for_each_program(prog, obj) {
 		prog_cnt++;
+
+		if (use_loader && !bpf_program__autoload(prog)) {
+			p_err("program '%s' is marked as non-autoload, which is not supported for light skeletons",
+			      bpf_program__name(prog));
+			return -1;
+		}
 	}
 
 	get_header_guard(header_guard, obj_name, "SKEL_H");
-- 
2.55.0.979.g7e5102b832-goog

Re: [PATCH bpf-next 2/2] bpftool: Reject non-autoload programs for light skeletons

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1387 bytes --]

> commit 2f59d25442273a3dd4e46bd4a77ca4bbf1633e3c
> Author: Thiébaud Weksteen <tweek@google.com>
> Date:   Fri Sep 4 13:19:12 2026 +1000
>
>     bpftool: Reject non-autoload programs for light skeletons
>
>     When generating a light skeleton (bpftool gen skeleton -L), there is no
>     libbpf runtime object or bpf_program__set_autoload() API available to
>     enable/disable the autoloading of programs. If a BPF program in the
>     object has autoload disabled (e.g. via SEC("?...")), bpf_object__load()
>     silently skips loading it. bpftool still generates struct bpf_prog_desc
>     fields and attach functions in the light skeleton header, leaving
>     skel->progs.<name>.prog_fd uninitialized (0).
>
>     Explicitly reject non-autoloaded programs when use_loader is true with
>     an error message, preventing the generation of broken light skeleton
>     headers.
>
>     Signed-off-by: Thiébaud Weksteen <tweek@google.com>

This looks like a bug fix for light skeleton generation. Should this
include a Fixes: tag?

  Fixes: d510296d331a ("bpftool: Use syscall/loader program in \"prog load\" and \"gen skeleton\" command.")


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/33833567672

Re: [PATCH bpf-next 1/2] selftests/bpf: Move verifier failure tests out of test_global_percpu_data

[Leon Hwang]

On 4/9/26 11:19, Thiébaud Weksteen wrote:
> Commit 4c9241bd731a ("selftests/bpf: Add tests to verify global percpu
> data") added test_global_percpu_data.c to LSKELS_EXTRA. Later, in commit
> 1ed2294b31fc ("selftests/bpf: Test verifier log for global percpu data")
> two verifier failure tests were added (verifier_strncmp and
> verifier_snprintf), both marked as non-autoload (SEC("?kprobe")).
> 
> When bpftool generates light skeletons, non-autoloaded programs are
> skipped during loading, causing the loader program to store subsequent
> program FDs into incorrect skeleton struct fields (e.g. dump_percpu_data's
> FD was stored into verifier_strncmp's descriptor).

IIUC, patch 2 will fix the issue totally.

Better to add a subtest to verify both the issue and the fix?

Thanks,
Leon

> [...]

Re: [PATCH bpf-next 1/2] selftests/bpf: Move verifier failure tests out of test_global_percpu_data

[Thiébaud Weksteen]

On Fri, Sep 4, 2026 at 4:07 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> On 4/9/26 11:19, Thiébaud Weksteen wrote:
> > Commit 4c9241bd731a ("selftests/bpf: Add tests to verify global percpu
> > data") added test_global_percpu_data.c to LSKELS_EXTRA. Later, in commit
> > 1ed2294b31fc ("selftests/bpf: Test verifier log for global percpu data")
> > two verifier failure tests were added (verifier_strncmp and
> > verifier_snprintf), both marked as non-autoload (SEC("?kprobe")).
> >
> > When bpftool generates light skeletons, non-autoloaded programs are
> > skipped during loading, causing the loader program to store subsequent
> > program FDs into incorrect skeleton struct fields (e.g. dump_percpu_data's
> > FD was stored into verifier_strncmp's descriptor).
>
> IIUC, patch 2 will fix the issue totally.
>
> Better to add a subtest to verify both the issue and the fix?

Thanks for the review. That's right, patch 2 will fix the issue:
bpftool will fail to build any program that is set up that way. That's
why patch 1 is necessary; otherwise, the existing test would fail.

Just checking your suggestion: what I can do is add a new test to make
sure that dump_percpu_data is set up as expected (fd > 0). I can write
a new test_global_percpu_data_iter_lskel, that is similar to
test_global_percpu_data_iter, but for lskel?

I can also write a test to ensure that bpftool fails when light
skeletons are set up with autoload=false?

Thanks,

Re: [PATCH bpf-next 2/2] bpftool: Reject non-autoload programs for light skeletons

[Quentin Monnet]

On 04/09/2026 04:19, Thiébaud Weksteen wrote:
> When generating a light skeleton (bpftool gen skeleton -L), there is no
> libbpf runtime object or bpf_program__set_autoload() API available to
> enable/disable the autoloading of programs. If a BPF program in the
> object has autoload disabled (e.g. via SEC("?...")), bpf_object__load()
> silently skips loading it. bpftool still generates struct bpf_prog_desc
> fields and attach functions in the light skeleton header, leaving
> skel->progs.<name>.prog_fd uninitialized (0).
> 
> Explicitly reject non-autoloaded programs when use_loader is true with
> an error message, preventing the generation of broken light skeleton
> headers.
> 
> Signed-off-by: Thiébaud Weksteen <tweek@google.com>
> ---
>  tools/bpf/bpftool/gen.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> index a50540ef6521..1583150241c8 100644
> --- a/tools/bpf/bpftool/gen.c
> +++ b/tools/bpf/bpftool/gen.c
> @@ -1340,6 +1340,12 @@ static int do_skeleton(int argc, char **argv)
>  	}
>  	bpf_object__for_each_program(prog, obj) {
>  		prog_cnt++;
> +
> +		if (use_loader && !bpf_program__autoload(prog)) {
> +			p_err("program '%s' is marked as non-autoload, which is not supported for light skeletons",
> +			      bpf_program__name(prog));
> +			return -1;


Sashiko is correct, at this stage of the function, rather than returning
directly, you'd need to "goto out".


> +		}


Thank you. Maybe consider adding a word about autoload/non-autoload in
"bpftool gen" man page? My concern is that users who are not familiar
with the notion will struggle to understand the error message.

Quentin

Re: [PATCH bpf-next 1/2] selftests/bpf: Move verifier failure tests out of test_global_percpu_data

[Leon Hwang]

On 2026/9/7 13:46, Thiébaud Weksteen wrote:
> On Fri, Sep 4, 2026 at 4:07 PM Leon Hwang <leon.hwang@linux.dev> wrote:
>>
>> On 4/9/26 11:19, Thiébaud Weksteen wrote:
>>> Commit 4c9241bd731a ("selftests/bpf: Add tests to verify global percpu
>>> data") added test_global_percpu_data.c to LSKELS_EXTRA. Later, in commit
>>> 1ed2294b31fc ("selftests/bpf: Test verifier log for global percpu data")
>>> two verifier failure tests were added (verifier_strncmp and
>>> verifier_snprintf), both marked as non-autoload (SEC("?kprobe")).
>>>
>>> When bpftool generates light skeletons, non-autoloaded programs are
>>> skipped during loading, causing the loader program to store subsequent
>>> program FDs into incorrect skeleton struct fields (e.g. dump_percpu_data's
>>> FD was stored into verifier_strncmp's descriptor).
>>
>> IIUC, patch 2 will fix the issue totally.
>>
>> Better to add a subtest to verify both the issue and the fix?
> 
> Thanks for the review. That's right, patch 2 will fix the issue:
> bpftool will fail to build any program that is set up that way. That's
> why patch 1 is necessary; otherwise, the existing test would fail.
> 
> Just checking your suggestion: what I can do is add a new test to make
> sure that dump_percpu_data is set up as expected (fd > 0). I can write
> a new test_global_percpu_data_iter_lskel, that is similar to
> test_global_percpu_data_iter, but for lskel?
> 
> I can also write a test to ensure that bpftool fails when light
> skeletons are set up with autoload=false?
> 

imo, the rejection of autoload=false prog when generating light skeleton
is not friendly for users. Users should not care about mixing
autoload=false progs with autoload=true progs, even for light skeletons.

The users-friendly way is to skip those autoload=false progs when
generating light skeletons.

So, this is a bpftool issue. A selftest is unnecessary. You can verify
both the issue and the fix manually. Probably, paste the verification
result in the patch message.

Thanks,
Leon

Re: [PATCH bpf-next 1/2] selftests/bpf: Move verifier failure tests out of test_global_percpu_data

[Thiébaud Weksteen]

On Tue, Sep 8, 2026 at 1:24 AM Leon Hwang <leon.hwang@linux.dev> wrote:
>
> On 2026/9/7 13:46, Thiébaud Weksteen wrote:
> > On Fri, Sep 4, 2026 at 4:07 PM Leon Hwang <leon.hwang@linux.dev> wrote:
> >>
> >> On 4/9/26 11:19, Thiébaud Weksteen wrote:
> >>> Commit 4c9241bd731a ("selftests/bpf: Add tests to verify global percpu
> >>> data") added test_global_percpu_data.c to LSKELS_EXTRA. Later, in commit
> >>> 1ed2294b31fc ("selftests/bpf: Test verifier log for global percpu data")
> >>> two verifier failure tests were added (verifier_strncmp and
> >>> verifier_snprintf), both marked as non-autoload (SEC("?kprobe")).
> >>>
> >>> When bpftool generates light skeletons, non-autoloaded programs are
> >>> skipped during loading, causing the loader program to store subsequent
> >>> program FDs into incorrect skeleton struct fields (e.g. dump_percpu_data's
> >>> FD was stored into verifier_strncmp's descriptor).
> >>
> >> IIUC, patch 2 will fix the issue totally.
> >>
> >> Better to add a subtest to verify both the issue and the fix?
> >
> > Thanks for the review. That's right, patch 2 will fix the issue:
> > bpftool will fail to build any program that is set up that way. That's
> > why patch 1 is necessary; otherwise, the existing test would fail.
> >
> > Just checking your suggestion: what I can do is add a new test to make
> > sure that dump_percpu_data is set up as expected (fd > 0). I can write
> > a new test_global_percpu_data_iter_lskel, that is similar to
> > test_global_percpu_data_iter, but for lskel?
> >
> > I can also write a test to ensure that bpftool fails when light
> > skeletons are set up with autoload=false?
> >
>
> imo, the rejection of autoload=false prog when generating light skeleton
> is not friendly for users. Users should not care about mixing
> autoload=false progs with autoload=true progs, even for light skeletons.
>
> The users-friendly way is to skip those autoload=false progs when
> generating light skeletons.

Good point. I agree. I'll send a patch with this approach instead. Thanks.

Re: [PATCH bpf-next 2/2] bpftool: Reject non-autoload programs for light skeletons

[Thiébaud Weksteen]

On Tue, Sep 8, 2026 at 1:24 AM Quentin Monnet <qmo@kernel.org> wrote:
>
> On 04/09/2026 04:19, Thiébaud Weksteen wrote:
> > When generating a light skeleton (bpftool gen skeleton -L), there is no
> > libbpf runtime object or bpf_program__set_autoload() API available to
> > enable/disable the autoloading of programs. If a BPF program in the
> > object has autoload disabled (e.g. via SEC("?...")), bpf_object__load()
> > silently skips loading it. bpftool still generates struct bpf_prog_desc
> > fields and attach functions in the light skeleton header, leaving
> > skel->progs.<name>.prog_fd uninitialized (0).
> >
> > Explicitly reject non-autoloaded programs when use_loader is true with
> > an error message, preventing the generation of broken light skeleton
> > headers.
> >
> > Signed-off-by: Thiébaud Weksteen <tweek@google.com>
> > ---
> >  tools/bpf/bpftool/gen.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> > index a50540ef6521..1583150241c8 100644
> > --- a/tools/bpf/bpftool/gen.c
> > +++ b/tools/bpf/bpftool/gen.c
> > @@ -1340,6 +1340,12 @@ static int do_skeleton(int argc, char **argv)
> >       }
> >       bpf_object__for_each_program(prog, obj) {
> >               prog_cnt++;
> > +
> > +             if (use_loader && !bpf_program__autoload(prog)) {
> > +                     p_err("program '%s' is marked as non-autoload, which is not supported for light skeletons",
> > +                           bpf_program__name(prog));
> > +                     return -1;
>
>
> Sashiko is correct, at this stage of the function, rather than returning
> directly, you'd need to "goto out".

Thanks for the review. I agree, I'm not sure how I missed that one.

>
>
> > +             }
>
>
> Thank you. Maybe consider adding a word about autoload/non-autoload in
> "bpftool gen" man page? My concern is that users who are not familiar
> with the notion will struggle to understand the error message.

Ack. I'll send a new patch to skip over these programs instead, as
suggested by Leon in the other patch ("selftests/bpf: Move verifier
failure tests out of test_global_percpu_data"). Thanks.