netdev - Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

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: <87r1xajgbd.fsf@toke.dk>
Date:   Mon, 30 Mar 2020 12:19:18 +0200
From:   Toke Høiland-Jørgensen <toke@...hat.com>
To:     Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc:     Andrii Nakryiko <andrii.nakryiko@...il.com>,
        John Fastabend <john.fastabend@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        Martin KaFai Lau <kafai@...com>,
        Song Liu <songliubraving@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        "David S. Miller" <davem@...emloft.net>,
        Jesper Dangaard Brouer <brouer@...hat.com>,
        Lorenz Bauer <lmb@...udflare.com>,
        Andrey Ignatov <rdna@...com>,
        Networking <netdev@...r.kernel.org>, bpf <bpf@...r.kernel.org>
Subject: Re: [PATCH bpf-next 1/4] xdp: Support specifying expected existing program when attaching XDP

Alexei Starovoitov <alexei.starovoitov@...il.com> writes:

> On Sun, Mar 29, 2020 at 12:39:21PM +0200, Toke Høiland-Jørgensen wrote:
>> 
>> > I guess all that is acceptable behavior to some libxdp users.
>> 
>> I believe so.
>
> Not for us. Sadly that's where we part ways. we will not be using your
> libxdp.

Up to you of course, but I must say that I'm a bit surprised that you
state this so categorically at this stage. As far as I'm concerned,
there is still plenty of opportunity for cooperation on this, and I'm
still quite willing to accommodate your needs in libxdp.

> Existing xdp api was barely usable in the datacenter environment. replace_fd
> makes no difference.
>
>> exclusivity does come in handy. And as I said, I can live with there
>> being two APIs as long as there's a reasonable way to override the
>> bpf_link "lock" :)
>
> I explained many times already that bpf_link for XDP is NOT a second api to do
> the same thing. I understand that you think it's a second api, but when you
> keep repeating 'second api' it makes other folks (who also don't understand the
> difference) to make wrong conclusions that they can use either to achieve the
> same thing. They cannot. And it makes my job explaining harder. So please drop
> 'second api' narrative.

I understand that they're different. Really, I do. That doesn't change
the fact that there will be two ways to install an XDP program, though.
Which is all I meant by "two APIs"; I was not implying they would be
completely equivalent in all ways.

-Toke