netdev - Re: [PATCH v3 bpf-next 07/17] libbpf: expose BTF-to-C type declaration emitting API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 13 Dec 2019 17:06:11 -0800
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Andrii Nakryiko <andriin@...com>, bpf <bpf@...r.kernel.org>,
        Networking <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v3 bpf-next 07/17] libbpf: expose BTF-to-C type
 declaration emitting API

On Fri, Dec 13, 2019 at 3:50 PM Alexei Starovoitov
<alexei.starovoitov@...il.com> wrote:
>
> On Fri, Dec 13, 2019 at 02:32:04PM -0800, Andrii Nakryiko wrote:
> > Expose API that allows to emit type declaration and field/variable definition
> > (if optional field name is specified) in valid C syntax for any provided BTF
> > type. This is going to be used by bpftool when emitting data section layout as
> > a struct. As part of making this API useful in a stand-alone fashion, move
> > initialization of some of the internal btf_dump state to earlier phase.
> >
> > Acked-by: Martin KaFai Lau <kafai@...com>
> > Signed-off-by: Andrii Nakryiko <andriin@...com>
> > ---
> >  tools/lib/bpf/btf.h      | 22 ++++++++++++++
> >  tools/lib/bpf/btf_dump.c | 62 +++++++++++++++++++++++-----------------
> >  tools/lib/bpf/libbpf.map |  1 +
> >  3 files changed, 59 insertions(+), 26 deletions(-)
> >
> > diff --git a/tools/lib/bpf/btf.h b/tools/lib/bpf/btf.h
> > index a114c8ef4f08..1f9625946ead 100644
> > --- a/tools/lib/bpf/btf.h
> > +++ b/tools/lib/bpf/btf.h
> > @@ -126,6 +126,28 @@ LIBBPF_API void btf_dump__free(struct btf_dump *d);
> >
> >  LIBBPF_API int btf_dump__dump_type(struct btf_dump *d, __u32 id);
> >
> > +struct btf_dump_emit_type_decl_opts {
> > +     /* size of this struct, for forward/backward compatiblity */
> > +     size_t sz;
> > +     /* optional field name for type declaration, e.g.:
> > +      * - struct my_struct <FNAME>
> > +      * - void (*<FNAME>)(int)
> > +      * - char (*<FNAME>)[123]
> > +      */
> > +     const char *field_name;
> > +     /* extra indentation level (in number of tabs) to emit for multi-line
> > +      * type declarations (e.g., anonymous struct); applies for lines
> > +      * starting from the second one (first line is assumed to have
> > +      * necessary indentation already
> > +      */
> > +     int indent_level;
> > +};
> > +#define btf_dump_emit_type_decl_opts__last_field attach_prog_fd
>
> OPTS_VALID() is missing in btf_dump__emit_type_decl() ?
> Otherwise it would have caught above typo.

duh... right, very good catch, thanks!

>
>
> >       d->ident_names = hashmap__new(str_hash_fn, str_equal_fn, NULL);
> >       if (IS_ERR(d->ident_names)) {
> >               err = PTR_ERR(d->ident_names);
> >               d->ident_names = NULL;
> > -             btf_dump__free(d);
> > -             return ERR_PTR(err);
> > +             goto err;
> > +     }
> > +     d->type_states = calloc(1 + btf__get_nr_types(d->btf),
> > +                             sizeof(d->type_states[0]));
> > +     if (!d->type_states) {
> > +             err = -ENOMEM;
> > +             goto err;
> > +     }
> > +     d->cached_names = calloc(1 + btf__get_nr_types(d->btf),
> > +                              sizeof(d->cached_names[0]));
> > +     if (!d->cached_names) {
> > +             err = -ENOMEM;
> > +             goto err;
> >       }
> >
> > +     /* VOID is special */
> > +     d->type_states[0].order_state = ORDERED;
> > +     d->type_states[0].emit_state = EMITTED;
>
> Not following the logic with 1 + btf__get_nr_types(d->btf) and
> above init...
> type_states[0] is void. true.
> But btf__get_nr_types() includes that type_id=0 == void.
> So what this 1+ is for?
> I know it's just a move of old code. I just noticed.
> Would be great to add a comment.

btf__get_nr_types() does not actually include void, thus we need +1.
It is confusing, I agree, but is consistent throughout libbpf.

>