Lennart Poettering aa2b6f1d2b bpf: rework how we keep track and attach cgroup bpf programs
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.
2018-02-21 16:43:36 +01:00
2018-02-16 13:01:12 +01:00
2018-02-19 11:59:26 +01:00
2018-01-19 21:48:14 -05:00
2017-12-07 17:12:13 +09:00
2018-01-12 18:02:57 +01:00
2017-11-29 14:33:56 +01:00
2018-02-14 09:43:49 +01:00
2017-12-25 19:48:49 +01:00
2016-10-06 11:53:58 -04:00
2018-02-20 17:25:05 +01:00

systemd - System and Service Manager

Count of open issues over time Count of open pull requests over time Build Status
Coverity Scan Status
CII Best Practices

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.

S
Description
systemd patched fork
Readme
409 MiB
Languages
C 88.5%
Shell 5.7%
Python 4.6%
Meson 1.1%