netdev - Re: [PATCH v4 bpf-next 0/9] BPF XDP link

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: <CAADnVQLMMxCh36EgPqqL9hkXkbEX2C-nhzT5N7eVdr4Rf7nSug@mail.gmail.com>
Date:   Sat, 25 Jul 2020 20:46:39 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Andrii Nakryiko <andriin@...com>
Cc:     bpf <bpf@...r.kernel.org>,
        Network Development <netdev@...r.kernel.org>,
        Alexei Starovoitov <ast@...com>,
        Daniel Borkmann <daniel@...earbox.net>,
        David Ahern <dsahern@...il.com>,
        Andrii Nakryiko <andrii.nakryiko@...il.com>,
        Kernel Team <kernel-team@...com>
Subject: Re: [PATCH v4 bpf-next 0/9] BPF XDP link

On Tue, Jul 21, 2020 at 11:46 PM Andrii Nakryiko <andriin@...com> wrote:
>
> Following cgroup and netns examples, implement bpf_link support for XDP.
>
> The semantics is described in patch #2. Program and link attachments are
> mutually exclusive, in the sense that neither link can replace attached
> program nor program can replace attached link. Link can't replace attached
> link as well, as is the case for any other bpf_link implementation.
>
> Patch #1 refactors existing BPF program-based attachment API and centralizes
> high-level query/attach decisions in generic kernel code, while drivers are
> kept simple and are instructed with low-level decisions about attaching and
> detaching specific bpf_prog. This also makes QUERY command unnecessary, and
> patch #8 removes support for it from all kernel drivers. If that's a bad idea,
> we can drop that patch altogether.
>
> With refactoring in patch #1, adding bpf_xdp_link is completely transparent to
> drivers, they are still functioning at the level of "effective" bpf_prog, that
> should be called in XDP data path.
>
> Corresponding libbpf support for BPF XDP link is added in patch #5.
>
> v3->v4:
> - fix a compilation warning in one of drivers (Jakub);

As far as I could review everything looks fine,
so I've applied the set.
The code is delicate. I wish people were more active doing code reviews.
So I encourage folks to still look at it. If there is anything missing I'm sure
Andrii will fix it up in the follow up.