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.