aa2b6f1d2b
So, the kernel's management of cgroup/BPF programs is a bit misdesigned: if you attach a BPF program to a cgroup and close the fd for it it will stay pinned to the cgroup with no chance of ever removing it again (or otherwise getting ahold of it again), because the fd is used for selecting which BPF program to detach. The only way to get rid of the program again is to destroy the cgroup itself. This is particularly bad for root the cgroup (and in fact any other cgroup that we cannot realistically remove during runtime, such as /system.slice, /init.scope or /system.slice/dbus.service) as getting rid of the program only works by rebooting the system. To counter this let's closely keep track to which cgroup a BPF program is attached and let's implicitly detach the BPF program when we are about to close the BPF fd. This hence changes the bpf_program_cgroup_attach() function to track where we attached the program and changes bpf_program_cgroup_detach() to use this information. Moreover bpf_program_unref() will now implicitly call bpf_program_cgroup_detach(). In order to simplify things, bpf_program_cgroup_attach() will now implicitly invoke bpf_program_load_kernel() when necessary, simplifying the caller's side. Finally, this adds proper reference counting to BPF programs. This is useful for working with two BPF programs in parallel: the BPF program we are preparing for installation and the BPF program we so far installed, shortening the window when we detach the old one and reattach the new one. |
||
|---|---|---|
| .github | ||
| .mkosi | ||
| catalog | ||
| coccinelle | ||
| docs | ||
| factory/etc | ||
| hwdb | ||
| man | ||
| modprobe.d | ||
| network | ||
| po | ||
| presets | ||
| rules | ||
| scripts | ||
| shell-completion | ||
| src | ||
| sysctl.d | ||
| sysusers.d | ||
| test | ||
| tmpfiles.d | ||
| tools | ||
| travis-ci | ||
| units | ||
| xorg | ||
| .dir-locals.el | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| .vimrc | ||
| .ycm_extra_conf.py | ||
| CODING_STYLE | ||
| configure | ||
| DISTRO_PORTING | ||
| ENVIRONMENT.md | ||
| HACKING | ||
| LICENSE.GPL2 | ||
| LICENSE.LGPL2.1 | ||
| Makefile | ||
| meson.build | ||
| meson_options.txt | ||
| mkosi.build | ||
| mkosi.default | ||
| NEWS | ||
| README | ||
| README.md | ||
| TODO | ||
| TRANSIENT-SETTINGS.md | ||
| UIDS-GIDS.md | ||
systemd - System and Service Manager
Details
General information about systemd can be found in the systemd Wiki.
Information about build requirements are provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the HACKING file for information how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list or join our IRC channel.