netdev - RE: [PATCH bpf-next 0/8] PROG_TEST_RUN support for sk

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]

Message-ID: <602d77b91e028_aed92087d@john-XPS-13-9370.notmuch>
Date:   Wed, 17 Feb 2021 12:08:25 -0800
From:   John Fastabend <john.fastabend@...il.com>
To:     Lorenz Bauer <lmb@...udflare.com>, ast@...nel.org,
        daniel@...earbox.net, andrii@...nel.org, jakub@...udflare.com
Cc:     kernel-team@...udflare.com, bpf@...r.kernel.org,
        netdev@...r.kernel.org, Lorenz Bauer <lmb@...udflare.com>
Subject: RE: [PATCH bpf-next 0/8] PROG_TEST_RUN support for sk_lookup programs

Lorenz Bauer wrote:
> We don't have PROG_TEST_RUN support for sk_lookup programs at the
> moment. So far this hasn't been a problem, since we can run our
> tests in a separate network namespace. For benchmarking it's nice
> to have PROG_TEST_RUN, so I've gone and implemented it.
> 
> Multiple sk_lookup programs can be attached at once to the same
> netns. This can't be expressed with the current PROG_TEST_RUN
> API, so I'm proposing to extend it with an array of prog_fd.
> 
> Patches 1-2 are clean ups. Patches 3-4 add the new UAPI and
> implement PROG_TEST_RUN for sk_lookup. Patch 5 adds a new
> function to libbpf to access multi prog tests. Patches 6-8 add
> tests.
> 
> Andrii, for patch 4 I decided on the following API:
> 
>     int bpf_prog_test_run_array(__u32 *prog_fds, __u32 prog_fds_cnt,
>                                 struct bpf_test_run_opts *opts)
> 
> To be consistent with the rest of libbpf it would be better
> to take int *prog_fds, but I think then the function would have to
> convert the array to account for platforms where
> 
>     sizeof(int) != sizeof(__u32)
> 
> Please let me know what your preference is.

Seems reasonable to me. For the series,

Acked-by: John Fastabend <john.fastabend@...il.com>