bpf_link abstraction itself was formalized in [0] with justifications for why its semantics is a good fit for attaching BPF programs of various types. This patch set adds bpf_link-based BPF program attachment mechanism for cgroup BPF programs. Cgroup BPF link implements all the modes and semantics of existing BPF program attachment: exclusive, exclusive overridable and multi-attachment. Thus cgroup bpf_link can co-exist with legacy BPF program multi-attachment. See patch #4 for detailed explanation of inter-operability between legacy and bpf_link-based attachments. bpf_link is destroyed and automatically detached when the last open FD holding the reference to bpf_link is closed. This means that by default, when the process that created bpf_link exits, attached BPF program will be automatically detached due to bpf_link's clean up code. Cgroup bpf_link, like any other bpf_link, can be pinned in BPF FS and by those means survive the exit of process that created the link. This is useful in many scenarios to provide long-living BPF program attachments. Pinning also means that there could be many owners of bpf_link through independent FDs. Additionally, auto-detachmet of cgroup bpf_link is implemented. When cgroup is dying it will automatically detach all active bpf_links. This ensures that cgroup clean up is not delayed due to active bpf_link even despite no chance for any BPF program to be run for a given cgroup. In that sense it's similar to existing behavior of dropping refcnt of attached bpf_prog. But in the case of bpf_link, bpf_link is not destroyed and is still available to user as long as at least one active FD is still open (or if it's pinned in BPF FS). There are two main cgroup-specific differences between bpf_link-based and direct bpf_prog-based attachment. First, as opposed to direct bpf_prog attachment, cgroup itself doesn't "own" bpf_link, which makes it possible to auto-clean up attached bpf_link when user process abruptly exits without explicitly detaching BPF program. This makes for a safe default behavior proven in BPF tracing program types. But bpf_link doesn't bump cgroup->bpf.refcnt as well and because of that doesn't prevent cgroup from cleaning up its BPF state. Second, only owners of bpf_link (those who created bpf_link in the first place or obtained a new FD by opening bpf_link from BPF FS) can detach and/or update it. This makes sure that no other process can accidentally remove/replace BPF program. This patch set also implements LINK_UPDATE sub-command, which allows to replace bpf_link's underlying bpf_prog, similarly to BPF_F_REPLACE flag behavior for direct bpf_prog cgroup attachment. Similarly to LINK_CREATE, it is supposed to be generic command for different types of bpf_links. [0] https://lore.kernel.org/bpf/20200228223948.360936-1-andriin@xxxxxx/ v1->v2: - implement exclusive and overridable exclusive modes (Andrey Ignatov); - fix build for !CONFIG_CGROUP_BPF build; - add more selftests for non-multi mode and inter-operability; Andrii Nakryiko (6): bpf: factor out cgroup storages operations bpf: factor out attach_type to prog_type mapping for attach/detach bpf: implement bpf_link-based cgroup BPF program attachment bpf: implement bpf_prog replacement for an active bpf_cgroup_link libbpf: add support for bpf_link-based cgroup attachment selftests/bpf: test FD-based cgroup attachment include/linux/bpf-cgroup.h | 40 +- include/linux/bpf.h | 10 +- include/uapi/linux/bpf.h | 22 +- kernel/bpf/cgroup.c | 518 ++++++++++++++---- kernel/bpf/syscall.c | 267 +++++---- kernel/cgroup/cgroup.c | 41 +- tools/include/uapi/linux/bpf.h | 22 +- tools/lib/bpf/bpf.c | 35 ++ tools/lib/bpf/bpf.h | 20 + tools/lib/bpf/libbpf.c | 49 ++ tools/lib/bpf/libbpf.h | 9 +- tools/lib/bpf/libbpf.map | 4 + .../selftests/bpf/prog_tests/cgroup_link.c | 235 ++++++++ .../selftests/bpf/progs/test_cgroup_link.c | 24 + 14 files changed, 1067 insertions(+), 229 deletions(-) create mode 100644 tools/testing/selftests/bpf/prog_tests/cgroup_link.c create mode 100644 tools/testing/selftests/bpf/progs/test_cgroup_link.c -- 2.17.1
