netdev - Re: [PATCH v5 bpf-next 0/4] capture integers in BTF type info for map defs

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] [day] [month] [year] [list]

Message-ID: <CAEf4BzY5g-2R4ZYT5veH4TydyB=iMTmqMk2fx3gSS2SOi=QaqA@mail.gmail.com>
Date:   Tue, 9 Jul 2019 14:39:57 -0700
From:   Andrii Nakryiko <andrii.nakryiko@...il.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     Daniel Borkmann <daniel@...earbox.net>,
        Andrii Nakryiko <andriin@...com>,
        Kernel Team <kernel-team@...com>,
        Alexei Starovoitov <ast@...com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH v5 bpf-next 0/4] capture integers in BTF type info for map defs

On Tue, Jul 9, 2019 at 1:27 PM Edward Cree <ecree@...arflare.com> wrote:
>
> On 05/07/2019 22:15, Daniel Borkmann wrote:
> > On 07/05/2019 05:50 PM, Andrii Nakryiko wrote:
> >> This patch set implements an update to how BTF-defined maps are specified. The
> >> change is in how integer attributes, e.g., type, max_entries, map_flags, are
> >> specified: now they are captured as part of map definition struct's BTF type
> >> information (using array dimension), eliminating the need for compile-time
> >> data initialization and keeping all the metadata in one place.
> >>
> >> All existing selftests that were using BTF-defined maps are updated, along
> >> with some other selftests, that were switched to new syntax.
> BTW is this changing the BTF format spec, and if so why isn't it accompanied by
>  a patch to Documentation/bpf/btf.rst?  It looks like that doc still talks about
>  BPF_ANNOTATE_KV_PAIR, which seems to be long gone.

It didn't remove BPF_ANNOTATE_KV_PAIR and you can still use it and
libbpf will continue supporting it for the time being. But I'll update
the doc with new syntax, thanks for reminding!


>
> -Ed