On Wed, Dec 18, 2019 at 10:14:04AM -0800, Andrii Nakryiko wrote: [ ... ] > > Where we do have problem is with bpf_link__destroy() unconditionally > also detaching whatever was attached (tracepoint, kprobe, or whatever > was done to create bpf_link in the first place). Now, > bpf_link__destroy() has to be called by user (or skeleton) to at least > free up malloc()'ed structs. But it appears that it's not always > desirable that upon bpf_link destruction underlying BPF program gets > detached. I think this will be the case for xdp and others as well. > > I think the good and generic way to go about this is to have this as a > general concept of destroying the link without detaching BPF programs. > E.g., what if we have new API call `void bpf_link__unlink()`, which > will mark that link as not requiring to detach underlying BPF program. > When bpf_link__destroy() is called later, it will just free resources > allocated to maintain bpf_link itself, but won't detach any BPF > programs/resources. > > With this, user will have to explicitly specify that he doesn't want > to detach even when skeleton/link is destroyed. If we get consensus on > this, I can add support for this to all the existing bpf_links and you > can build on that? Keeping the current struct_ops unreg mechanism (i.e. bpf_struct_ops__unregister(), to be renamed) and having a way to opt-out sounds good to me. Thanks.
