[PATCH] bpftool: mmaped fields missing map structure in generated skeletons

[PATCH] bpftool: mmaped fields missing map structure in generated skeletons

[Michael Mullin]

When generating a skeleton which has an mmaped map field, bpftool's
output is missing the map structure.  This causes a compile break when
the generated skeleton is compiled as the field belongs to the internal
struct maps, not directly to the obj.

Signed-off-by: Michael Mullin <masmullin@gmail.com>
---
 tools/bpf/bpftool/gen.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
index f158dc1c2149..b49293795ba0 100644
--- a/tools/bpf/bpftool/gen.c
+++ b/tools/bpf/bpftool/gen.c
@@ -853,7 +853,7 @@ codegen_maps_skeleton(struct bpf_object *obj, size_t map_cnt, bool mmaped)
 			i, bpf_map__name(map), i, ident);
 		/* memory-mapped internal maps */
 		if (mmaped && is_internal_mmapable_map(map, ident, sizeof(ident))) {
-			printf("\ts->maps[%zu].mmaped = (void **)&obj->%s;\n",
+			printf("\ts->maps[%zu].mmaped = (void **)&obj->maps.%s;\n",
 				i, ident);
 		}
 		i++;
-- 
2.36.1

Re: [PATCH] bpftool: mmaped fields missing map structure in generated skeletons

[Andrii Nakryiko]

On Mon, May 23, 2022 at 1:26 PM Michael Mullin <masmullin@gmail.com> wrote:
>
> When generating a skeleton which has an mmaped map field, bpftool's
> output is missing the map structure.  This causes a compile break when
> the generated skeleton is compiled as the field belongs to the internal
> struct maps, not directly to the obj.
>
> Signed-off-by: Michael Mullin <masmullin@gmail.com>
> ---
>  tools/bpf/bpftool/gen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> index f158dc1c2149..b49293795ba0 100644
> --- a/tools/bpf/bpftool/gen.c
> +++ b/tools/bpf/bpftool/gen.c
> @@ -853,7 +853,7 @@ codegen_maps_skeleton(struct bpf_object *obj, size_t map_cnt, bool mmaped)
>                         i, bpf_map__name(map), i, ident);
>                 /* memory-mapped internal maps */
>                 if (mmaped && is_internal_mmapable_map(map, ident, sizeof(ident))) {
> -                       printf("\ts->maps[%zu].mmaped = (void **)&obj->%s;\n",
> +                       printf("\ts->maps[%zu].mmaped = (void **)&obj->maps.%s;\n",

That's not right. maps.my_map is struct bpf_map *, but mmaped is
supposed to be a blob of memory that is memory-mapped into map.

Can you elaborate on how you trigger that compilation error with a
small example?

>                                 i, ident);
>                 }
>                 i++;
> --
> 2.36.1
>

Re: [PATCH] bpftool: mmaped fields missing map structure in generated skeletons

[Michael Mullin]

On Mon, May 23, 2022 at 03:02:31PM -0700, Andrii Nakryiko wrote:
> On Mon, May 23, 2022 at 1:26 PM Michael Mullin <masmullin@gmail.com> wrote:
> >
> > When generating a skeleton which has an mmaped map field, bpftool's
> > output is missing the map structure.  This causes a compile break when
> > the generated skeleton is compiled as the field belongs to the internal
> > struct maps, not directly to the obj.
> >
> > Signed-off-by: Michael Mullin <masmullin@gmail.com>
> > ---
> >  tools/bpf/bpftool/gen.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> > index f158dc1c2149..b49293795ba0 100644
> > --- a/tools/bpf/bpftool/gen.c
> > +++ b/tools/bpf/bpftool/gen.c
> > @@ -853,7 +853,7 @@ codegen_maps_skeleton(struct bpf_object *obj, size_t map_cnt, bool mmaped)
> >                         i, bpf_map__name(map), i, ident);
> >                 /* memory-mapped internal maps */
> >                 if (mmaped && is_internal_mmapable_map(map, ident, sizeof(ident))) {
> > -                       printf("\ts->maps[%zu].mmaped = (void **)&obj->%s;\n",
> > +                       printf("\ts->maps[%zu].mmaped = (void **)&obj->maps.%s;\n",
> 
> That's not right. maps.my_map is struct bpf_map *, but mmaped is
> supposed to be a blob of memory that is memory-mapped into map.
> 
> Can you elaborate on how you trigger that compilation error with a
> small example?

I have an a very small example on github. I have added some sed fixes to
my Makefile make my sample program compile.
https://github.com/masmullin2000/libbpf-sample/tree/main/c/simple

https://github.com/masmullin2000/libbpf-sample/tree/02c7f945bf9027daedec04f485a320ba2df28204/c/simple
contains broken code.

I apologize if this is an incorrect way to share external code.  I
haven't found the proper way to share example code from
kernelnewbies.org

> 
> >                                 i, ident);
> >                 }
> >                 i++;
> > --
> > 2.36.1
> >

Re: [PATCH] bpftool: mmaped fields missing map structure in generated skeletons

[Andrii Nakryiko]

On Mon, May 23, 2022 at 3:19 PM Michael Mullin <masmullin@gmail.com> wrote:
>
> On Mon, May 23, 2022 at 03:02:31PM -0700, Andrii Nakryiko wrote:
> > On Mon, May 23, 2022 at 1:26 PM Michael Mullin <masmullin@gmail.com> wrote:
> > >
> > > When generating a skeleton which has an mmaped map field, bpftool's
> > > output is missing the map structure.  This causes a compile break when
> > > the generated skeleton is compiled as the field belongs to the internal
> > > struct maps, not directly to the obj.
> > >
> > > Signed-off-by: Michael Mullin <masmullin@gmail.com>
> > > ---
> > >  tools/bpf/bpftool/gen.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> > > index f158dc1c2149..b49293795ba0 100644
> > > --- a/tools/bpf/bpftool/gen.c
> > > +++ b/tools/bpf/bpftool/gen.c
> > > @@ -853,7 +853,7 @@ codegen_maps_skeleton(struct bpf_object *obj, size_t map_cnt, bool mmaped)
> > >                         i, bpf_map__name(map), i, ident);
> > >                 /* memory-mapped internal maps */
> > >                 if (mmaped && is_internal_mmapable_map(map, ident, sizeof(ident))) {
> > > -                       printf("\ts->maps[%zu].mmaped = (void **)&obj->%s;\n",
> > > +                       printf("\ts->maps[%zu].mmaped = (void **)&obj->maps.%s;\n",
> >
> > That's not right. maps.my_map is struct bpf_map *, but mmaped is
> > supposed to be a blob of memory that is memory-mapped into map.
> >
> > Can you elaborate on how you trigger that compilation error with a
> > small example?
>
> I have an a very small example on github. I have added some sed fixes to
> my Makefile make my sample program compile.
> https://github.com/masmullin2000/libbpf-sample/tree/main/c/simple
>
> https://github.com/masmullin2000/libbpf-sample/tree/02c7f945bf9027daedec04f485a320ba2df28204/c/simple
> contains broken code.

You are missing -g when calling clang to generate debug info (DWARF
and subsequently BTF). When BPF object file doesn't have BTF, we don't
generate those bss/data/rodata/etc sections of the skeleton. You
should be good just by adding -g.

>
> I apologize if this is an incorrect way to share external code.  I
> haven't found the proper way to share example code from
> kernelnewbies.org
>
> >
> > >                                 i, ident);
> > >                 }
> > >                 i++;
> > > --
> > > 2.36.1
> > >

Re: [PATCH] bpftool: mmaped fields missing map structure in generated skeletons

[Michael Mullin]

On Mon, May 23, 2022 at 03:38:03PM -0700, Andrii Nakryiko wrote:
> On Mon, May 23, 2022 at 3:19 PM Michael Mullin <masmullin@gmail.com> wrote:
> >
> > On Mon, May 23, 2022 at 03:02:31PM -0700, Andrii Nakryiko wrote:
> > > On Mon, May 23, 2022 at 1:26 PM Michael Mullin <masmullin@gmail.com> wrote:
> > > >
> > > > When generating a skeleton which has an mmaped map field, bpftool's
> > > > output is missing the map structure.  This causes a compile break when
> > > > the generated skeleton is compiled as the field belongs to the internal
> > > > struct maps, not directly to the obj.
> > > >
> > > > Signed-off-by: Michael Mullin <masmullin@gmail.com>
> > > > ---
> > > >  tools/bpf/bpftool/gen.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/tools/bpf/bpftool/gen.c b/tools/bpf/bpftool/gen.c
> > > > index f158dc1c2149..b49293795ba0 100644
> > > > --- a/tools/bpf/bpftool/gen.c
> > > > +++ b/tools/bpf/bpftool/gen.c
> > > > @@ -853,7 +853,7 @@ codegen_maps_skeleton(struct bpf_object *obj, size_t map_cnt, bool mmaped)
> > > >                         i, bpf_map__name(map), i, ident);
> > > >                 /* memory-mapped internal maps */
> > > >                 if (mmaped && is_internal_mmapable_map(map, ident, sizeof(ident))) {
> > > > -                       printf("\ts->maps[%zu].mmaped = (void **)&obj->%s;\n",
> > > > +                       printf("\ts->maps[%zu].mmaped = (void **)&obj->maps.%s;\n",
> > >
> > > That's not right. maps.my_map is struct bpf_map *, but mmaped is
> > > supposed to be a blob of memory that is memory-mapped into map.
> > >
> > > Can you elaborate on how you trigger that compilation error with a
> > > small example?
> >
> > I have an a very small example on github. I have added some sed fixes to
> > my Makefile make my sample program compile.
> > https://github.com/masmullin2000/libbpf-sample/tree/main/c/simple
> >
> > https://github.com/masmullin2000/libbpf-sample/tree/02c7f945bf9027daedec04f485a320ba2df28204/c/simple
> > contains broken code.
> 
> You are missing -g when calling clang to generate debug info (DWARF
> and subsequently BTF). When BPF object file doesn't have BTF, we don't
> generate those bss/data/rodata/etc sections of the skeleton. You
> should be good just by adding -g.
> 

Thank you. By using -g, I am also unable to trigger the segfault
I was trying to fix with the patch
https://lore.kernel.org/bpf/20220523194917.igkgorco42537arb@jup/T/#u

I am not sure if there would be other ways to trigger the segfault.

> >
> > I apologize if this is an incorrect way to share external code.  I
> > haven't found the proper way to share example code from
> > kernelnewbies.org
> >
> > >
> > > >                                 i, ident);
> > > >                 }
> > > >                 i++;
> > > > --
> > > > 2.36.1
> > > >