On Mon, Mar 2, 2020 at 8:32 PM Andrii Nakryiko <andriin@xxxxxx> wrote: > > This patch series adds bpf_link abstraction, analogous to libbpf's already > existing bpf_link abstraction. This formalizes and makes more uniform existing > bpf_link-like BPF program link (attachment) types (raw tracepoint and tracing > links), which are FD-based objects that are automatically detached when last > file reference is closed. These types of BPF program links are switched to > using bpf_link framework. > > FD-based bpf_link approach provides great safety guarantees, by ensuring there > is not going to be an abandoned BPF program attached, if user process suddenly > exits or forgets to clean up after itself. This is especially important in > production environment and is what all the recent new BPF link types followed. > > One of the previously existing inconveniences of FD-based approach, though, > was the scenario in which user process wants to install BPF link and exit, but > let attached BPF program run. Now, with bpf_link abstraction in place, it's > easy to support pinning links in BPF FS, which is done as part of the same > patch #1. This allows FD-based BPF program links to survive exit of a user > process and original file descriptor being closed, by creating an file entry > in BPF FS. This provides great safety by default, with simple way to opt out > for cases where it's needed. > > Corresponding libbpf APIs are added in the same patch set, as well as > selftests for this functionality. > > Other types of BPF program attachments (XDP, cgroup, perf_event, etc) are > going to be converted in subsequent patches to follow similar approach. Applied. Thanks.
