[PATCH bpf-next 1/2] bpftool: Skip non-autoload programs when generating light skeletons

[PATCH bpf-next 1/2] bpftool: Skip non-autoload programs when generating light skeletons

[Thiébaud Weksteen]

When generating a light skeleton (bpftool gen skeleton -L),
bpf_object__load() skips loading programs marked as non-autoload (e.g.
SEC("?...")), so the generated loader program only records and populates
file descriptors for autoloaded programs.

Previously, bpftool emitted struct bpf_prog_desc fields, link fields,
and attach/detach/destroy functions for all programs in the BPF object,
causing the loader program to store subsequent program FDs into
incorrect skeleton struct fields when non-autoload programs were
present.

Skip programs with !bpf_program__autoload(prog) when counting programs
and generating progs/links struct fields as well as attach, detach, and
destroy functions for light skeletons.

Fixes: d510296d331a ("bpftool: Use syscall/loader program in "prog load" and "gen skeleton" command.")
Signed-off-by: Thiébaud Weksteen <tweek@google.com>
---
 tools/bpf/bpftool/Documentation/bpftool-gen.rst |  4 +++-
 tools/bpf/bpftool/gen.c                         | 15 +++++++++++++++
 2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/tools/bpf/bpftool/Documentation/bpftool-gen.rst b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
index d0a36f442db7..1cdecf3e4fa5 100644
--- a/tools/bpf/bpftool/Documentation/bpftool-gen.rst
+++ b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
@@ -184,7 +184,9 @@ OPTIONS
 -L, --use-loader
     For skeletons, generate a "light" skeleton (also known as "loader"
     skeleton). A light skeleton contains a loader eBPF program. It does not use
-    the majority of the libbpf infrastructure, and does not need libelf.
+    the majority of the libbpf infrastructure, and does not need libelf. BPF
+    programs marked as non-autoload (e.g., via **SEC("?...")**) are skipped and
+    not included in the generated skeleton.
 
 -S, --sign
     For skeletons, generate a signed skeleton. This option must be used with
diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
index a50540ef6521..0fcfe20ff515 100644
--- a/tools/bpf/bpftool/gen.c
+++ b/tools/bpf/bpftool/gen.c
@@ -583,6 +583,9 @@ static void codegen_attach_detach(struct bpf_object *obj, const char *obj_name)
 	bpf_object__for_each_program(prog, obj) {
 		const char *tp_name;
 
+		if (!bpf_program__autoload(prog))
+			continue;
+
 		codegen("\
 			\n\
 			\n\
@@ -629,6 +632,8 @@ static void codegen_attach_detach(struct bpf_object *obj, const char *obj_name)
 		", obj_name);
 
 	bpf_object__for_each_program(prog, obj) {
+		if (!bpf_program__autoload(prog))
+			continue;
 		codegen("\
 			\n\
 				ret = ret < 0 ? ret : %1$s__%2$s__attach(skel);   \n\
@@ -646,6 +651,8 @@ static void codegen_attach_detach(struct bpf_object *obj, const char *obj_name)
 		", obj_name);
 
 	bpf_object__for_each_program(prog, obj) {
+		if (!bpf_program__autoload(prog))
+			continue;
 		codegen("\
 			\n\
 				skel_closenz(skel->links.%1$s_fd);	    \n\
@@ -676,6 +683,8 @@ static void codegen_destroy(struct bpf_object *obj, const char *obj_name)
 		obj_name);
 
 	bpf_object__for_each_program(prog, obj) {
+		if (!bpf_program__autoload(prog))
+			continue;
 		codegen("\
 			\n\
 				skel_closenz(skel->progs.%1$s.prog_fd);	    \n\
@@ -1339,6 +1348,8 @@ static int do_skeleton(int argc, char **argv)
 		map_cnt++;
 	}
 	bpf_object__for_each_program(prog, obj) {
+		if (use_loader && !bpf_program__autoload(prog))
+			continue;
 		prog_cnt++;
 	}
 
@@ -1402,6 +1413,8 @@ static int do_skeleton(int argc, char **argv)
 	if (prog_cnt) {
 		printf("\tstruct {\n");
 		bpf_object__for_each_program(prog, obj) {
+			if (use_loader && !bpf_program__autoload(prog))
+				continue;
 			if (use_loader)
 				printf("\t\tstruct bpf_prog_desc %s;\n",
 				       bpf_program__name(prog));
@@ -1415,6 +1428,8 @@ static int do_skeleton(int argc, char **argv)
 	if (prog_cnt + attach_map_cnt) {
 		printf("\tstruct {\n");
 		bpf_object__for_each_program(prog, obj) {
+			if (use_loader && !bpf_program__autoload(prog))
+				continue;
 			if (use_loader)
 				printf("\t\tint %s_fd;\n",
 				       bpf_program__name(prog));
-- 
2.55.0.979.g7e5102b832-goog

[PATCH bpf-next 2/2] selftests/bpf: Verify program FD after non-autoload programs in lskel

[Thiébaud Weksteen]

In test_global_percpu_data.c, dump_percpu_data is defined after two
non-autoload SEC("?kprobe") programs (verifier_strncmp and
verifier_snprintf). Verify in test_global_percpu_data_lskel() that
lskel->progs.dump_percpu_data.prog_fd is properly populated (> 0) when
loaded via the light skeleton.

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>
---
 tools/testing/selftests/bpf/prog_tests/global_data_init.c | 2 ++
 1 file changed, 2 insertions(+)

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..ebda60200b71 100644
--- a/tools/testing/selftests/bpf/prog_tests/global_data_init.c
+++ b/tools/testing/selftests/bpf/prog_tests/global_data_init.c
@@ -214,6 +214,8 @@ static void test_global_percpu_data_lskel(void)
 	lskel = test_global_percpu_data_lskel__open_and_load();
 	if (!ASSERT_OK_PTR(lskel, "test_global_percpu_data_lskel__open_and_load"))
 		goto out;
+	if (!ASSERT_GT(lskel->progs.dump_percpu_data.prog_fd, 0, "dump_percpu_data.prog_fd"))
+		goto out;
 
 	map_fd = lskel->maps.percpu.map_fd;
 	prog_fd = lskel->progs.update_percpu_data.prog_fd;
-- 
2.55.0.979.g7e5102b832-goog

Re: [PATCH bpf-next 2/2] selftests/bpf: Verify program FD after non-autoload programs in lskel

[bot+bpf-ci]

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

> In test_global_percpu_data.c, dump_percpu_data is defined after two
> non-autoload SEC("?kprobe") programs (verifier_strncmp and
> verifier_snprintf). Verify in test_global_percpu_data_lskel() that
> lskel->progs.dump_percpu_data.prog_fd is properly populated (> 0) when
> loaded via the light skeleton.
>
> Fixes: 4c9241bd731a ("selftests/bpf: Add tests to verify global percpu data")
> Fixes: 1ed2294b31fc ("selftests/bpf: Test verifier log for global percpu data")

The existing Fixes tags point to commits 4c9241bd731a and 1ed2294b31fc,
but the specific test scenario being verified here (dump_percpu_data
program appearing after non-autoload programs) was only fully introduced
by commit 15945d02c6e1.

While the earlier commits laid groundwork (4c9241bd731a added
test_global_percpu_data_lskel(), 1ed2294b31fc added non-autoload
programs), the dump_percpu_data program itself was added in 15945d02c6e1.

Would it be more accurate to use:

  Fixes: 15945d02c6e1 ("selftests/bpf: Verify bpf_iter for global percpu data")


---
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/34245369055

Re: [PATCH bpf-next 1/2] bpftool: Skip non-autoload programs when generating light skeletons

[bot+bpf-ci]

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

> diff --git a/tools/bpf/bpftool/Documentation/bpftool-gen.rst b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
> index d0a36f442db7..1cdecf3e4fa5 100644
> --- a/tools/bpf/bpftool/Documentation/bpftool-gen.rst
> +++ b/tools/bpf/bpftool/Documentation/bpftool-gen.rst

[ ... ]

> diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> index a50540ef6521..0fcfe20ff515 100644
> --- a/tools/bpf/bpftool/gen.c
> +++ b/tools/bpf/bpftool/gen.c
> @@ -583,6 +583,9 @@ static void codegen_attach_detach(struct bpf_object *obj, const char *obj_name)
>  	bpf_object__for_each_program(prog, obj) {
>  		const char *tp_name;
>
> +		if (!bpf_program__autoload(prog))
> +			continue;
> +
>  		codegen("\
>  			\n\
>  			\n\

[ ... ]

> @@ -1339,6 +1348,8 @@ static int do_skeleton(int argc, char **argv)
>  		map_cnt++;
>  	}
>  	bpf_object__for_each_program(prog, obj) {
> +		if (use_loader && !bpf_program__autoload(prog))
> +			continue;
>  		prog_cnt++;
>  	}

Can the autoload flag change between when this check runs and when
codegen_attach_detach() checks it?

Looking at the code flow, do_skeleton() samples bpf_program__autoload() here
before calling bpf_object__load(), but codegen_attach_detach() and
codegen_destroy() (which also check autoload at gen.c:586, 635, 654, and 686)
run inside gen_trace() after bpf_object__load() completes.

In tools/lib/bpf/libbpf.c, bpf_object__load() ->
bpf_object_prepare() modifies prog->autoload for struct_ops programs:

1. bpf_object__init_kern_struct_ops_maps() (libbpf.c:1251, 1290) sets
   st_ops->progs[i]->autoload = false when the member is missing from kernel
   BTF or the slot was replaced/NULLed.

2. bpf_object_adjust_struct_ops_autoload() (libbpf.c:1166) sets
   prog->autoload = should_load for programs referenced by struct_ops maps,
   which can flip SEC("?struct_ops/...") programs from false back to true when
   the referencing map has autocreate set.

For the false->true case (SEC("?struct_ops/foo") with an autocreated map):
do_skeleton() omits both the progs and links struct fields, but
codegen_attach_detach()/codegen_destroy() then emit attach functions
referencing skel->progs.foo.prog_fd and skel->links.foo_fd, which weren't
declared.

For the true->false case (plain SEC("struct_ops/foo") whose member is missing
from kernel BTF): the fields are emitted but attach/detach/destroy skip the
program, and the loader doesn't reserve a prog_fd slot for it, so subsequent
program FDs get written into preceding fields.

Would it work to sample autoload once and reuse that decision, or to move the
struct field emission after bpf_object__load()?

> @@ -1402,6 +1413,8 @@ static int do_skeleton(int argc, char **argv)
>  	if (prog_cnt) {
>  		printf("\tstruct {\n");
>  		bpf_object__for_each_program(prog, obj) {
> +			if (use_loader && !bpf_program__autoload(prog))
> +				continue;
>  			if (use_loader)
>  				printf("\t\tstruct bpf_prog_desc %s;\n",
>  				       bpf_program__name(prog));

[ ... ]

> @@ -1415,6 +1428,8 @@ static int do_skeleton(int argc, char **argv)
>  	if (prog_cnt + attach_map_cnt) {
>  		printf("\tstruct {\n");
>  		bpf_object__for_each_program(prog, obj) {
> +			if (use_loader && !bpf_program__autoload(prog))
> +				continue;
>  			if (use_loader)
>  				printf("\t\tint %s_fd;\n",
>  				       bpf_program__name(prog));


---
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/34245369055

Re: [PATCH bpf-next 1/2] bpftool: Skip non-autoload programs when generating light skeletons

[Quentin Monnet]

On 08/09/2026 17:01, bot+bpf-ci@kernel.org wrote:
>> diff --git a/tools/bpf/bpftool/Documentation/bpftool-gen.rst b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
>> index d0a36f442db7..1cdecf3e4fa5 100644
>> --- a/tools/bpf/bpftool/Documentation/bpftool-gen.rst
>> +++ b/tools/bpf/bpftool/Documentation/bpftool-gen.rst
> 
> [ ... ]
> 
>> diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
>> index a50540ef6521..0fcfe20ff515 100644
>> --- a/tools/bpf/bpftool/gen.c
>> +++ b/tools/bpf/bpftool/gen.c
>> @@ -583,6 +583,9 @@ static void codegen_attach_detach(struct bpf_object *obj, const char *obj_name)
>>  	bpf_object__for_each_program(prog, obj) {
>>  		const char *tp_name;
>>
>> +		if (!bpf_program__autoload(prog))
>> +			continue;
>> +
>>  		codegen("\
>>  			\n\
>>  			\n\
> 
> [ ... ]
> 
>> @@ -1339,6 +1348,8 @@ static int do_skeleton(int argc, char **argv)
>>  		map_cnt++;
>>  	}
>>  	bpf_object__for_each_program(prog, obj) {
>> +		if (use_loader && !bpf_program__autoload(prog))
>> +			continue;
>>  		prog_cnt++;
>>  	}
> 
> Can the autoload flag change between when this check runs and when
> codegen_attach_detach() checks it?
> 
> Looking at the code flow, do_skeleton() samples bpf_program__autoload() here
> before calling bpf_object__load(), but codegen_attach_detach() and
> codegen_destroy() (which also check autoload at gen.c:586, 635, 654, and 686)
> run inside gen_trace() after bpf_object__load() completes.
> 
> In tools/lib/bpf/libbpf.c, bpf_object__load() ->
> bpf_object_prepare() modifies prog->autoload for struct_ops programs:
> 
> 1. bpf_object__init_kern_struct_ops_maps() (libbpf.c:1251, 1290) sets
>    st_ops->progs[i]->autoload = false when the member is missing from kernel
>    BTF or the slot was replaced/NULLed.
> 
> 2. bpf_object_adjust_struct_ops_autoload() (libbpf.c:1166) sets
>    prog->autoload = should_load for programs referenced by struct_ops maps,
>    which can flip SEC("?struct_ops/...") programs from false back to true when
>    the referencing map has autocreate set.
> 
> For the false->true case (SEC("?struct_ops/foo") with an autocreated map):
> do_skeleton() omits both the progs and links struct fields, but
> codegen_attach_detach()/codegen_destroy() then emit attach functions
> referencing skel->progs.foo.prog_fd and skel->links.foo_fd, which weren't
> declared.
> 
> For the true->false case (plain SEC("struct_ops/foo") whose member is missing
> from kernel BTF): the fields are emitted but attach/detach/destroy skip the
> program, and the loader doesn't reserve a prog_fd slot for it, so subsequent
> program FDs get written into preceding fields.
> 
> Would it work to sample autoload once and reuse that decision, or to move the
> struct field emission after bpf_object__load()?

It looks like both Sashiko and the bpf-ci bot raised valid concerns.
Here, it's probably cleaner to move the struct field emission after
bpf_object__load()? Seems a bit more involved though, we'd need to move
these struct field emission to gen_trace() for the use_loader case, or
move bpf_object__load() out of gen_trace(), not sure which is best. This
way we'd have the fields printed after bpf_object__load() has updated
(if necessary) the autoload status for "obj", and
codegen_attach_detach() would then use the correct fields.

Quentin