From 82370ed5ade58d99484a607a6000fc8333921c63 Mon Sep 17 00:00:00 2001 From: Andrii Nakryiko Date: Thu, 10 Oct 2024 14:17:31 -0700 Subject: [PATCH] selftests/bpf: add subprog to BPF object file with no entry programs Add a subprogram to BPF object file that otherwise has no entry BPF programs to validate that libbpf can still load this correctly. Until this was fixed, user could expect this very confusing error message: libbpf: prog 'dangling_subprog': missing BPF prog type, check ELF section name '.text' libbpf: prog 'dangling_subprog': failed to load: -22 libbpf: failed to load object 'struct_ops_detach' libbpf: failed to load BPF skeleton 'struct_ops_detach': -22 Signed-off-by: Andrii Nakryiko Link: https://lore.kernel.org/r/20241010211731.4121837-2-andrii@kernel.org Signed-off-by: Alexei Starovoitov --- .../testing/selftests/bpf/progs/struct_ops_detach.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/tools/testing/selftests/bpf/progs/struct_ops_detach.c b/tools/testing/selftests/bpf/progs/struct_ops_detach.c index 56b787a89876..d7fdcabe7d90 100644 --- a/tools/testing/selftests/bpf/progs/struct_ops_detach.c +++ b/tools/testing/selftests/bpf/progs/struct_ops_detach.c @@ -6,5 +6,17 @@ char _license[] SEC("license") = "GPL"; +/* + * This subprogram validates that libbpf handles the situation in which BPF + * object has subprograms in .text section, but has no entry BPF programs. + * At some point that was causing issues due to legacy logic of treating such + * subprogram as entry program (with unknown program type, which would fail). + */ +int dangling_subprog(void) +{ + /* do nothing, just be here */ + return 0; +} + SEC(".struct_ops.link") struct bpf_testmod_ops testmod_do_detach; -- 2.50.1