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:   Sun, 29 Mar 2020 12:26:50 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Toke Høiland-Jørgensen <toke@...hat.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

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.
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ