On Fri, Mar 27, 2020 at 11:06:59AM +0000, Lorenz Bauer wrote: > > From your description I like bpf_link, because it'll make attachment easier > to support, and the pinning behaviour also seems nice. I'm really not fussed > by netlink vs syscall, whatever. > > However, this behaviour concerns me. It's like Windows not > letting you delete a file while an application has it opened, which just leads > to randomly killing programs until you find the right one. It's frustrating > and counter productive. > > You're taking power away from the operator. In your deployment scenario > this might make sense, but I think it's a really bad model in general. If I am > privileged I need to be able to exercise that privilege. This means that if > there is a netdevice in my network namespace, and I have CAP_NET_ADMIN > or whatever, I can break the association. I think I read a lot of assumptions in the above statement that are not the case. Let me clarify: bpf_link will not freeze the netdev that you cannot move it. If you want to ifdown it. It's fine. It can go down. If you want to move it to another netns it's also fine. bpf_link based attachment either will become dangling or continue to exist in a different namespace. That behavior is tbd. If bpf_link was attached to veth and you want to delete that veth that's also fine. bpf_link will surely be dangling at this point. bpf_link is about preserving the ownership of the attachment of a program to a netdev. I don't see how this is comparable with deletion of files in windows.
