summaryrefslogtreecommitdiff
path: root/tools/lib/ctype.c
diff options
context:
space:
mode:
authorAndrii Nakryiko <andriin@fb.com>2019-12-18 14:50:39 -0800
committerAlexei Starovoitov <ast@kernel.org>2019-12-18 17:17:47 -0800
commitd69587062c347314a019cf6ee27f2e4b494868e1 (patch)
treec399059a6df18b80651de4df41a206deece5360a /tools/lib/ctype.c
parent6de6c1f840c051017f2308503858ff19344c56b3 (diff)
libbpf: Add bpf_link__disconnect() API to preserve underlying BPF resource
There are cases in which BPF resource (program, map, etc) has to outlive userspace program that "installed" it in the system in the first place. When BPF program is attached, libbpf returns bpf_link object, which is supposed to be destroyed after no longer necessary through bpf_link__destroy() API. Currently, bpf_link destruction causes both automatic detachment and frees up any resources allocated to for bpf_link in-memory representation. This is inconvenient for the case described above because of coupling of detachment and resource freeing. This patch introduces bpf_link__disconnect() API call, which marks bpf_link as disconnected from its underlying BPF resouces. This means that when bpf_link is destroyed later, all its memory resources will be freed, but BPF resource itself won't be detached. This design allows to follow strict and resource-leak-free design by default, while giving easy and straightforward way for user code to opt for keeping BPF resource attached beyond lifetime of a bpf_link. For some BPF programs (i.e., FS-based tracepoints, kprobes, raw tracepoint, etc), user has to make sure to pin BPF program to prevent kernel to automatically detach it on process exit. This should typically be achived by pinning BPF program (or map in some cases) in BPF FS. Signed-off-by: Andrii Nakryiko <andriin@fb.com> Signed-off-by: Alexei Starovoitov <ast@kernel.org> Acked-by: Martin KaFai Lau <kafai@fb.com> Link: https://lore.kernel.org/bpf/20191218225039.2668205-1-andriin@fb.com
Diffstat (limited to 'tools/lib/ctype.c')
0 files changed, 0 insertions, 0 deletions