mbox series

[bpf-next,0/3] Strip away modifiers from BPF skeleton global variables

Message ID 20200701064527.3158178-1-andriin@fb.com
Headers show
Series Strip away modifiers from BPF skeleton global variables | expand

Message

Andrii Nakryiko July 1, 2020, 6:45 a.m. UTC
Fix bpftool logic of stripping away const/volatile modifiers for all global
variables during BPF skeleton generation. See patch #1 for details on when
existing logic breaks and why it's important. Support special .strip_mods=true
mode in btf_dump. Add selftests validating that everything works as expected.

Recent example of when this has caused problems can be found in [0].

  [0] https://github.com/iovisor/bcc/pull/2994#issuecomment-650588533

Cc: Anton Protopopov <a.s.protopopov@gmail.com>

Andrii Nakryiko (3):
  libbpf: support stripping modifiers for btf_dump
  selftests/bpf: add selftest validating btf_dump's mod-stripping output
  tools/bpftool: strip away modifiers from global variables

 tools/bpf/bpftool/gen.c                       | 13 ++---
 tools/lib/bpf/btf.h                           |  6 +++
 tools/lib/bpf/btf_dump.c                      | 18 +++++--
 .../selftests/bpf/prog_tests/btf_dump.c       |  5 +-
 .../selftests/bpf/prog_tests/skeleton.c       |  6 +--
 .../bpf/progs/btf_dump_test_case_strip_mods.c | 50 +++++++++++++++++++
 .../selftests/bpf/progs/test_skeleton.c       |  6 ++-
 7 files changed, 84 insertions(+), 20 deletions(-)
 create mode 100644 tools/testing/selftests/bpf/progs/btf_dump_test_case_strip_mods.c

Comments

Alexei Starovoitov July 1, 2020, 3:01 p.m. UTC | #1
On Tue, Jun 30, 2020 at 11:46 PM Andrii Nakryiko <andriin@fb.com> wrote:
>
> Fix bpftool logic of stripping away const/volatile modifiers for all global
> variables during BPF skeleton generation. See patch #1 for details on when
> existing logic breaks and why it's important. Support special .strip_mods=true
> mode in btf_dump. Add selftests validating that everything works as expected.

Why bother with the flag?
It looks like bugfix to me.
Andrii Nakryiko July 1, 2020, 4:08 p.m. UTC | #2
On Wed, Jul 1, 2020 at 8:02 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Jun 30, 2020 at 11:46 PM Andrii Nakryiko <andriin@fb.com> wrote:
> >
> > Fix bpftool logic of stripping away const/volatile modifiers for all global
> > variables during BPF skeleton generation. See patch #1 for details on when
> > existing logic breaks and why it's important. Support special .strip_mods=true
> > mode in btf_dump. Add selftests validating that everything works as expected.
>
> Why bother with the flag?

You mean btf_dump should do this always? That's a bit too invasive a
change, I don't like it.

> It looks like bugfix to me.

It can be considered a bug fix for bpftool's skeleton generation, but
it depends on non-trivial changes in libbpf, which are not bug fix per
se, so should probably better go through bpf-next.
Alexei Starovoitov July 1, 2020, 4:36 p.m. UTC | #3
On Wed, Jul 01, 2020 at 09:08:45AM -0700, Andrii Nakryiko wrote:
> On Wed, Jul 1, 2020 at 8:02 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> >
> > On Tue, Jun 30, 2020 at 11:46 PM Andrii Nakryiko <andriin@fb.com> wrote:
> > >
> > > Fix bpftool logic of stripping away const/volatile modifiers for all global
> > > variables during BPF skeleton generation. See patch #1 for details on when
> > > existing logic breaks and why it's important. Support special .strip_mods=true
> > > mode in btf_dump. Add selftests validating that everything works as expected.
> >
> > Why bother with the flag?
> 
> You mean btf_dump should do this always? That's a bit too invasive a
> change, I don't like it.
> 
> > It looks like bugfix to me.
> 
> It can be considered a bug fix for bpftool's skeleton generation, but
> it depends on non-trivial changes in libbpf, which are not bug fix per
> se, so should probably better go through bpf-next.

I'm not following.
Without tweaking opts and introducing new flag the actual fix is only
two hunks in patch 1:

@@ -1045,6 +1050,10 @@ static void btf_dump_emit_type_decl(struct btf_dump *d, __u32 id,

 	stack_start = d->decl_stack_cnt;
 	for (;;) {
+		t = btf__type_by_id(d->btf, id);
+		if (btf_is_mod(t))
+			goto skip_mod;
+
 		err = btf_dump_push_decl_stack_id(d, id);
 		if (err < 0) {
 			/*
@@ -1056,12 +1065,11 @@ static void btf_dump_emit_type_decl(struct btf_dump *d, __u32 id,
 			d->decl_stack_cnt = stack_start;
 			return;
 		}
-
+skip_mod:
 		/* VOID */
 		if (id == 0)
 			break;

-		t = btf__type_by_id(d->btf, id);
Andrii Nakryiko July 1, 2020, 6:15 p.m. UTC | #4
On Wed, Jul 1, 2020 at 9:36 AM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Jul 01, 2020 at 09:08:45AM -0700, Andrii Nakryiko wrote:
> > On Wed, Jul 1, 2020 at 8:02 AM Alexei Starovoitov
> > <alexei.starovoitov@gmail.com> wrote:
> > >
> > > On Tue, Jun 30, 2020 at 11:46 PM Andrii Nakryiko <andriin@fb.com> wrote:
> > > >
> > > > Fix bpftool logic of stripping away const/volatile modifiers for all global
> > > > variables during BPF skeleton generation. See patch #1 for details on when
> > > > existing logic breaks and why it's important. Support special .strip_mods=true
> > > > mode in btf_dump. Add selftests validating that everything works as expected.
> > >
> > > Why bother with the flag?
> >
> > You mean btf_dump should do this always? That's a bit too invasive a
> > change, I don't like it.
> >
> > > It looks like bugfix to me.
> >
> > It can be considered a bug fix for bpftool's skeleton generation, but
> > it depends on non-trivial changes in libbpf, which are not bug fix per
> > se, so should probably better go through bpf-next.
>
> I'm not following.
> Without tweaking opts and introducing new flag the actual fix is only
> two hunks in patch 1:

Right, but from the btf_dump point of view this is not a bug fix, its
current behavior is correct and precise. So this change is a change in
behavior and not universally correct for all the possible use cases.
So I can't just make it always strip modifiers, it's changing
generated output. It has to be an optional feature.


>
> @@ -1045,6 +1050,10 @@ static void btf_dump_emit_type_decl(struct btf_dump *d, __u32 id,
>
>         stack_start = d->decl_stack_cnt;
>         for (;;) {
> +               t = btf__type_by_id(d->btf, id);
> +               if (btf_is_mod(t))
> +                       goto skip_mod;
> +
>                 err = btf_dump_push_decl_stack_id(d, id);
>                 if (err < 0) {
>                         /*
> @@ -1056,12 +1065,11 @@ static void btf_dump_emit_type_decl(struct btf_dump *d, __u32 id,
>                         d->decl_stack_cnt = stack_start;
>                         return;
>                 }
> -
> +skip_mod:
>                 /* VOID */
>                 if (id == 0)
>                         break;
>
> -               t = btf__type_by_id(d->btf, id);
>