netdev - Re: [PATCH bpf-next v2 07/12] bpftool: Extract helpers for showing link attach type

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:   Tue, 02 Jun 2020 11:37:09 +0200
From:   Jakub Sitnicki <jakub@...udflare.com>
To:     Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc:     bpf <bpf@...r.kernel.org>, Networking <netdev@...r.kernel.org>,
        kernel-team@...udflare.com, Andrii Nakryiko <andriin@...com>
Subject: Re: [PATCH bpf-next v2 07/12] bpftool: Extract helpers for showing link attach type

On Tue, Jun 02, 2020 at 12:35 AM CEST, Andrii Nakryiko wrote:
> On Sun, May 31, 2020 at 1:32 AM Jakub Sitnicki <jakub@...udflare.com> wrote:
>>
>> Code for printing link attach_type is duplicated in a couple of places, and
>> likely will be duplicated for future link types as well. Create helpers to
>> prevent duplication.
>>
>> Suggested-by: Andrii Nakryiko <andriin@...com>
>> Signed-off-by: Jakub Sitnicki <jakub@...udflare.com>
>> ---
>
> LGTM, minor nit below.
>
> Acked-by: Andrii Nakryiko <andriin@...com>
>
>>  tools/bpf/bpftool/link.c | 44 ++++++++++++++++++++--------------------
>>  1 file changed, 22 insertions(+), 22 deletions(-)
>>
>> diff --git a/tools/bpf/bpftool/link.c b/tools/bpf/bpftool/link.c
>> index 670a561dc31b..1ff416eff3d7 100644
>> --- a/tools/bpf/bpftool/link.c
>> +++ b/tools/bpf/bpftool/link.c
>> @@ -62,6 +62,15 @@ show_link_header_json(struct bpf_link_info *info, json_writer_t *wtr)
>>         jsonw_uint_field(json_wtr, "prog_id", info->prog_id);
>>  }
>>
>> +static void show_link_attach_type_json(__u32 attach_type, json_writer_t *wtr)
>
> nit: if you look at jsonw_uint_field/jsonw_string_field, they accept
> json_write_t as a first argument, because they are sort of working on
> "object" json_writer_t. I think that's good and consistent. No big
> deal, but if you can adjust it for consistency, it would be good.

I followed show_link_header_json example here. I'm guessing the
intention was to keep show_link_header_json and show_link_header_plain
consistent, as the former takes an extra arg (wtr).

>
>> +{
>> +       if (attach_type < ARRAY_SIZE(attach_type_name))
>> +               jsonw_string_field(wtr, "attach_type",
>> +                                  attach_type_name[attach_type]);
>> +       else
>> +               jsonw_uint_field(wtr, "attach_type", attach_type);
>> +}
>> +
>
> [...]