[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <53515939-00bb-174c-bc55-f90eaceac2a3@solarflare.com>
Date: Mon, 30 Mar 2020 16:41:46 +0100
From: Edward Cree <ecree@...arflare.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>,
Toke Høiland-Jørgensen <toke@...hat.com>
CC: Alexei Starovoitov <alexei.starovoitov@...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 29/03/2020 21:23, Andrii Nakryiko wrote:
> But you can't say the same about other XDP applications that do not
> use libxdp. So will your library come with a huge warning
What about a system-wide policy switch to decide whether replacing/
removing an XDP program without EXPECTED_FD is allowed? That way
the sysadmin gets to choose whether it's the firewall or the packet
analyser that breaks, rather than baking a policy into the design.
Then libxdp just needs to say in the README "you might want to turn
on this switch". Or maybe it defaults to on, and the other program
has to talk you into turning it off if it wants to be 'ill-behaved'.
Either way, affected users will be driven to the kernel's
documentation for the policy switch, where we can tell them whatever
we think they need to know.
-ed
Powered by blists - more mailing lists