diff mbox series

[bpf-next,2/2] libbpf: fix BPF skeleton forward/backward compat handling

Message ID 20240704001527.754710-3-andrii@kernel.org (mailing list archive)
State Superseded
Delegated to: BPF
Headers show
Series Fix libbpf BPF skeleton forward/backward compat | expand

Checks

Context Check Description
netdev/series_format success Posting correctly formatted
netdev/tree_selection success Clearly marked for bpf-next
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 8 this patch: 8
netdev/build_tools success Errors and warnings before: 2 this patch: 2
netdev/cc_maintainers fail 1 blamed authors not CCed: martin.lau@linux.dev; 9 maintainers not CCed: yonghong.song@linux.dev haoluo@google.com jolsa@kernel.org song@kernel.org john.fastabend@gmail.com eddyz87@gmail.com kpsingh@kernel.org martin.lau@linux.dev sdf@google.com
netdev/build_clang success Errors and warnings before: 8 this patch: 8
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success Fixes tag looks correct
netdev/build_allmodconfig_warn success Errors and warnings before: 8 this patch: 8
netdev/checkpatch warning WARNING: Co-developed-by and Signed-off-by: name/email do not match WARNING: line length of 82 exceeds 80 columns WARNING: line length of 83 exceeds 80 columns WARNING: line length of 86 exceeds 80 columns WARNING: line length of 87 exceeds 80 columns WARNING: line length of 89 exceeds 80 columns WARNING: line length of 93 exceeds 80 columns
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
bpf/vmtest-bpf-next-VM_Test-2 success Logs for Unittests
bpf/vmtest-bpf-next-VM_Test-9 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-5 success Logs for aarch64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-next-VM_Test-14 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-10 success Logs for aarch64-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-7 success Logs for aarch64-gcc / test (test_progs, false, 360) / test_progs on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-15 success Logs for s390x-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-18 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-29 success Logs for x86_64-llvm-17 / build-release / build for x86_64 with llvm-17-O2
bpf/vmtest-bpf-next-VM_Test-21 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-38 success Logs for x86_64-llvm-18 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-26 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-32 success Logs for x86_64-llvm-17 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-13 fail Logs for s390x-gcc / test (test_maps, false, 360) / test_maps on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-19 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-23 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-30 success Logs for x86_64-llvm-17 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-40 success Logs for x86_64-llvm-18 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-4 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-31 success Logs for x86_64-llvm-17 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-37 success Logs for x86_64-llvm-18 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-36 success Logs for x86_64-llvm-18 / build-release / build for x86_64 with llvm-18-O2
bpf/vmtest-bpf-next-VM_Test-42 success Logs for x86_64-llvm-18 / veristat
bpf/vmtest-bpf-next-VM_Test-11 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-next-VM_Test-27 success Logs for x86_64-gcc / veristat / veristat on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-20 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-next-VM_Test-41 success Logs for x86_64-llvm-18 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-28 success Logs for x86_64-llvm-17 / build / build for x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-8 success Logs for aarch64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-34 success Logs for x86_64-llvm-17 / veristat
bpf/vmtest-bpf-next-PR fail PR summary
bpf/vmtest-bpf-next-VM_Test-16 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-35 success Logs for x86_64-llvm-18 / build / build for x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-12 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-22 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-25 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-39 success Logs for x86_64-llvm-18 / test (test_progs_cpuv4, false, 360) / test_progs_cpuv4 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-24 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-6 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-3 success Logs for Validate matrix.py
bpf/vmtest-bpf-next-VM_Test-33 success Logs for x86_64-llvm-17 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-17 success Logs for s390x-gcc / veristat

Commit Message

Andrii Nakryiko July 4, 2024, 12:15 a.m. UTC 
BPF skeleton was designed from day one to be extensible. Generated BPF
skeleton code specifies actual sizes of map/prog/variable skeletons for
that reason and libbpf is supposed to work with newer/older versions
correctly.

Unfortunately, it was missed that we implicitly embed hard-coded most
up-to-date (according to libbpf's version of libbpf.h header used to
compile BPF skeleton header) sizes of those strucs, which can differ
from the actual sizes at runtime when libbpf is used as a shared
library.

We have a few places were we just index array of maps/progs/vars, which
implicitly uses these potentially invalid sizes of structs.

This patch aims to fix this problem going forward. Once this lands,
we'll backport these changes in Github repo to create patched releases
for older libbpfs.

Fixes: d66562fba1ce ("libbpf: Add BPF object skeleton support")
Fixes: 430025e5dca5 ("libbpf: Add subskeleton scaffolding")
Co-developed-by: Mykyta Yatsenko <yatsenko@meta.com>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
---
 tools/lib/bpf/libbpf.c | 47 ++++++++++++++++++++++++------------------
 1 file changed, 27 insertions(+), 20 deletions(-)

Comments

Alan Maguire July 4, 2024, 3:16 p.m. UTC | #1 
On 04/07/2024 01:15, Andrii Nakryiko wrote:
> BPF skeleton was designed from day one to be extensible. Generated BPF
> skeleton code specifies actual sizes of map/prog/variable skeletons for
> that reason and libbpf is supposed to work with newer/older versions
> correctly.
> 
> Unfortunately, it was missed that we implicitly embed hard-coded most
> up-to-date (according to libbpf's version of libbpf.h header used to
> compile BPF skeleton header) sizes of those strucs, which can differ
> from the actual sizes at runtime when libbpf is used as a shared
> library.
> 
> We have a few places were we just index array of maps/progs/vars, which
> implicitly uses these potentially invalid sizes of structs.
> 
> This patch aims to fix this problem going forward. Once this lands,
> we'll backport these changes in Github repo to create patched releases
> for older libbpfs.
> 
> Fixes: d66562fba1ce ("libbpf: Add BPF object skeleton support")
> Fixes: 430025e5dca5 ("libbpf: Add subskeleton scaffolding")

Great catch! I suppose it also sort of

Fixes: 08ac454e258 ("libbpf: Auto-attach struct_ops BPF maps in BPF
skeleton")

...since that introduced the new bpf_map_skeleton field. Not a big deal
since it's new and not a stable backport candidate.

> Co-developed-by: Mykyta Yatsenko <yatsenko@meta.com>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>

I'm guessing that you found this when auto-attach silently didn't happen?

Nit: would it be worth dropping a debug logging message here


        /* Skeleton is created with earlier version of bpftool
         * which does not support auto-attachment
         */
-        if (s->map_skel_sz < sizeof(struct bpf_map_skeleton))
+        if (s->map_skel_sz < sizeof(struct bpf_map_skeleton)) {
+		pr_debug("libbpf version mismatch, cannot auto-attach\n");
		return 0;
+	}

...as it's a hard issue to spot?

For the series:

Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Eduard Zingerman July 4, 2024, 8:51 p.m. UTC | #2 
On Wed, 2024-07-03 at 17:15 -0700, Andrii Nakryiko wrote:
> BPF skeleton was designed from day one to be extensible. Generated BPF
> skeleton code specifies actual sizes of map/prog/variable skeletons for
> that reason and libbpf is supposed to work with newer/older versions
> correctly.
> 
> Unfortunately, it was missed that we implicitly embed hard-coded most
> up-to-date (according to libbpf's version of libbpf.h header used to
> compile BPF skeleton header) sizes of those strucs, which can differ
                                                  ^^
                                          nit: "struct"
> from the actual sizes at runtime when libbpf is used as a shared
> library.
> 
> We have a few places were we just index array of maps/progs/vars, which
> implicitly uses these potentially invalid sizes of structs.
> 
> This patch aims to fix this problem going forward. Once this lands,
> we'll backport these changes in Github repo to create patched releases
> for older libbpfs.
> 
> Fixes: d66562fba1ce ("libbpf: Add BPF object skeleton support")
> Fixes: 430025e5dca5 ("libbpf: Add subskeleton scaffolding")
> Co-developed-by: Mykyta Yatsenko <yatsenko@meta.com>
> Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> ---

I double-checked all uses of bpf_object_skeleton->{maps,progs},
all seems in order.

Acked-by: Eduard Zingerman <eddyz87@gmail.com>

[...]
Eduard Zingerman July 4, 2024, 8:56 p.m. UTC | #3 
On Thu, 2024-07-04 at 16:16 +0100, Alan Maguire wrote:

[...]

> Nit: would it be worth dropping a debug logging message here
> 
> 
>         /* Skeleton is created with earlier version of bpftool
>          * which does not support auto-attachment
>          */
> -        if (s->map_skel_sz < sizeof(struct bpf_map_skeleton))
> +        if (s->map_skel_sz < sizeof(struct bpf_map_skeleton)) {
> +		pr_debug("libbpf version mismatch, cannot auto-attach\n");
> 		return 0;
> +	}
> 
> ...as it's a hard issue to spot?

+1 for debug message, but this is not an error condition,
so I'd say something like "..., skipping auto-attach for struct_ops".
Andrii Nakryiko July 8, 2024, 5:19 p.m. UTC | #4 
On Thu, Jul 4, 2024 at 8:17 AM Alan Maguire <alan.maguire@oracle.com> wrote:
>
> On 04/07/2024 01:15, Andrii Nakryiko wrote:
> > BPF skeleton was designed from day one to be extensible. Generated BPF
> > skeleton code specifies actual sizes of map/prog/variable skeletons for
> > that reason and libbpf is supposed to work with newer/older versions
> > correctly.
> >
> > Unfortunately, it was missed that we implicitly embed hard-coded most
> > up-to-date (according to libbpf's version of libbpf.h header used to
> > compile BPF skeleton header) sizes of those strucs, which can differ
> > from the actual sizes at runtime when libbpf is used as a shared
> > library.
> >
> > We have a few places were we just index array of maps/progs/vars, which
> > implicitly uses these potentially invalid sizes of structs.
> >
> > This patch aims to fix this problem going forward. Once this lands,
> > we'll backport these changes in Github repo to create patched releases
> > for older libbpfs.
> >
> > Fixes: d66562fba1ce ("libbpf: Add BPF object skeleton support")
> > Fixes: 430025e5dca5 ("libbpf: Add subskeleton scaffolding")
>
> Great catch! I suppose it also sort of
>
> Fixes: 08ac454e258 ("libbpf: Auto-attach struct_ops BPF maps in BPF
> skeleton")
>
> ...since that introduced the new bpf_map_skeleton field. Not a big deal
> since it's new and not a stable backport candidate.
>

yeah, I put the original changes that introduced this
bug/inflexibility in the first place. Either way Github releases and
backporting will be done separate from the kernel repo.

> > Co-developed-by: Mykyta Yatsenko <yatsenko@meta.com>
> > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
>
> I'm guessing that you found this when auto-attach silently didn't happen?

nope, we actually got crashes due to memory corruption in our internal
production testing

>
> Nit: would it be worth dropping a debug logging message here
>
>
>         /* Skeleton is created with earlier version of bpftool
>          * which does not support auto-attachment
>          */
> -        if (s->map_skel_sz < sizeof(struct bpf_map_skeleton))
> +        if (s->map_skel_sz < sizeof(struct bpf_map_skeleton)) {
> +               pr_debug("libbpf version mismatch, cannot auto-attach\n");

ok, sure. But as Eduard pointed out, it's not really a bug or anything
like that, it's an expected backwards compat mechanism. I can add
debug-level (or probably info-level?) message, though.

>                 return 0;
> +       }
>
> ...as it's a hard issue to spot?
>
> For the series:
>
> Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Andrii Nakryiko July 8, 2024, 5:19 p.m. UTC | #5 
On Thu, Jul 4, 2024 at 1:56 PM Eduard Zingerman <eddyz87@gmail.com> wrote:
>
> On Thu, 2024-07-04 at 16:16 +0100, Alan Maguire wrote:
>
> [...]
>
> > Nit: would it be worth dropping a debug logging message here
> >
> >
> >         /* Skeleton is created with earlier version of bpftool
> >          * which does not support auto-attachment
> >          */
> > -        if (s->map_skel_sz < sizeof(struct bpf_map_skeleton))
> > +        if (s->map_skel_sz < sizeof(struct bpf_map_skeleton)) {
> > +             pr_debug("libbpf version mismatch, cannot auto-attach\n");
> >               return 0;
> > +     }
> >
> > ...as it's a hard issue to spot?
>
> +1 for debug message, but this is not an error condition,
> so I'd say something like "..., skipping auto-attach for struct_ops".

agreed, thinking to make it info-level and only output if we actually
have struct_ops, so not to spam people unnecessarily
diff mbox series

Patch

diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
index 4a28fac4908a..e92f933267d1 100644
--- a/tools/lib/bpf/libbpf.c
+++ b/tools/lib/bpf/libbpf.c
@@ -13712,14 +13712,15 @@  int libbpf_num_possible_cpus(void)
 
 static int populate_skeleton_maps(const struct bpf_object *obj,
 				  struct bpf_map_skeleton *maps,
-				  size_t map_cnt)
+				  size_t map_cnt, size_t map_skel_sz)
 {
 	int i;
 
 	for (i = 0; i < map_cnt; i++) {
-		struct bpf_map **map = maps[i].map;
-		const char *name = maps[i].name;
-		void **mmaped = maps[i].mmaped;
+		struct bpf_map_skeleton *map_skel = (void *)maps + i * map_skel_sz;
+		struct bpf_map **map = map_skel->map;
+		const char *name = map_skel->name;
+		void **mmaped = map_skel->mmaped;
 
 		*map = bpf_object__find_map_by_name(obj, name);
 		if (!*map) {
@@ -13736,13 +13737,14 @@  static int populate_skeleton_maps(const struct bpf_object *obj,
 
 static int populate_skeleton_progs(const struct bpf_object *obj,
 				   struct bpf_prog_skeleton *progs,
-				   size_t prog_cnt)
+				   size_t prog_cnt, size_t prog_skel_sz)
 {
 	int i;
 
 	for (i = 0; i < prog_cnt; i++) {
-		struct bpf_program **prog = progs[i].prog;
-		const char *name = progs[i].name;
+		struct bpf_prog_skeleton *prog_skel = (void *)progs + i * prog_skel_sz;
+		struct bpf_program **prog = prog_skel->prog;
+		const char *name = prog_skel->name;
 
 		*prog = bpf_object__find_program_by_name(obj, name);
 		if (!*prog) {
@@ -13783,13 +13785,13 @@  int bpf_object__open_skeleton(struct bpf_object_skeleton *s,
 	}
 
 	*s->obj = obj;
-	err = populate_skeleton_maps(obj, s->maps, s->map_cnt);
+	err = populate_skeleton_maps(obj, s->maps, s->map_cnt, s->map_skel_sz);
 	if (err) {
 		pr_warn("failed to populate skeleton maps for '%s': %d\n", s->name, err);
 		return libbpf_err(err);
 	}
 
-	err = populate_skeleton_progs(obj, s->progs, s->prog_cnt);
+	err = populate_skeleton_progs(obj, s->progs, s->prog_cnt, s->prog_skel_sz);
 	if (err) {
 		pr_warn("failed to populate skeleton progs for '%s': %d\n", s->name, err);
 		return libbpf_err(err);
@@ -13819,20 +13821,20 @@  int bpf_object__open_subskeleton(struct bpf_object_subskeleton *s)
 		return libbpf_err(-errno);
 	}
 
-	err = populate_skeleton_maps(s->obj, s->maps, s->map_cnt);
+	err = populate_skeleton_maps(s->obj, s->maps, s->map_cnt, s->map_skel_sz);
 	if (err) {
 		pr_warn("failed to populate subskeleton maps: %d\n", err);
 		return libbpf_err(err);
 	}
 
-	err = populate_skeleton_progs(s->obj, s->progs, s->prog_cnt);
+	err = populate_skeleton_progs(s->obj, s->progs, s->prog_cnt, s->prog_skel_sz);
 	if (err) {
 		pr_warn("failed to populate subskeleton maps: %d\n", err);
 		return libbpf_err(err);
 	}
 
 	for (var_idx = 0; var_idx < s->var_cnt; var_idx++) {
-		var_skel = &s->vars[var_idx];
+		var_skel = (void *)s->vars + var_idx * s->var_skel_sz;
 		map = *var_skel->map;
 		map_type_id = bpf_map__btf_value_type_id(map);
 		map_type = btf__type_by_id(btf, map_type_id);
@@ -13879,10 +13881,11 @@  int bpf_object__load_skeleton(struct bpf_object_skeleton *s)
 	}
 
 	for (i = 0; i < s->map_cnt; i++) {
-		struct bpf_map *map = *s->maps[i].map;
+		struct bpf_map_skeleton *map_skel = (void *)s->maps + i * s->map_skel_sz;
+		struct bpf_map *map = *map_skel->map;
 		size_t mmap_sz = bpf_map_mmap_sz(map);
 		int prot, map_fd = map->fd;
-		void **mmaped = s->maps[i].mmaped;
+		void **mmaped = map_skel->mmaped;
 
 		if (!mmaped)
 			continue;
@@ -13930,8 +13933,9 @@  int bpf_object__attach_skeleton(struct bpf_object_skeleton *s)
 	int i, err;
 
 	for (i = 0; i < s->prog_cnt; i++) {
-		struct bpf_program *prog = *s->progs[i].prog;
-		struct bpf_link **link = s->progs[i].link;
+		struct bpf_prog_skeleton *prog_skel = (void *)s->progs + i * s->prog_skel_sz;
+		struct bpf_program *prog = *prog_skel->prog;
+		struct bpf_link **link = prog_skel->link;
 
 		if (!prog->autoload || !prog->autoattach)
 			continue;
@@ -13970,8 +13974,9 @@  int bpf_object__attach_skeleton(struct bpf_object_skeleton *s)
 		return 0;
 
 	for (i = 0; i < s->map_cnt; i++) {
-		struct bpf_map *map = *s->maps[i].map;
-		struct bpf_link **link = s->maps[i].link;
+		struct bpf_map_skeleton *map_skel = (void *)s->maps + i * s->map_skel_sz;
+		struct bpf_map *map = *map_skel->map;
+		struct bpf_link **link = map_skel->link;
 
 		if (!map->autocreate || !map->autoattach)
 			continue;
@@ -14000,7 +14005,8 @@  void bpf_object__detach_skeleton(struct bpf_object_skeleton *s)
 	int i;
 
 	for (i = 0; i < s->prog_cnt; i++) {
-		struct bpf_link **link = s->progs[i].link;
+		struct bpf_prog_skeleton *prog_skel = (void *)s->progs + i * s->prog_skel_sz;
+		struct bpf_link **link = prog_skel->link;
 
 		bpf_link__destroy(*link);
 		*link = NULL;
@@ -14010,7 +14016,8 @@  void bpf_object__detach_skeleton(struct bpf_object_skeleton *s)
 		return;
 
 	for (i = 0; i < s->map_cnt; i++) {
-		struct bpf_link **link = s->maps[i].link;
+		struct bpf_map_skeleton *map_skel = (void *)s->maps + i * s->map_skel_sz;
+		struct bpf_link **link = map_skel->link;
 
 		if (link) {
 			bpf_link__destroy(*link);