Thread (120 messages) 120 messages, 12 authors, 2020-05-13

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

From: Jakub Kicinski <kuba@kernel.org>
Date: 2020-03-30 19:13:19
Also in: bpf

On Mon, 30 Mar 2020 16:41:46 +0100 Edward Cree wrote:
On 29/03/2020 21:23, Andrii Nakryiko wrote:
quoted
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.
I had the same thought. But then again all samples specify IF_NOEXIST
AFAICS, and users will file bugs for replacing other apps. IMHO it's
kind of a responsibility of the distro to make sure that apps it packages
don't break each other. 

The mechanism to be well behaved exists, it's the sad reality of
backward compatibility that we can't just make it enforced by default
(IF_NOEXIST vs ALLOW_REPLACE).

So adding a knob seems perfectly reasonable, but perhaps we should see
one or two examples of apps actually getting it wrong before adding a
knob?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help