On 06/29, Quentin Monnet wrote:
Bpftool used to bump the memlock rlimit to make sure to be able to load
BPF objects. After the kernel has switched to memcg-based memory
accounting [0] in 5.11, bpftool has relied on libbpf to probe the system
for memcg-based accounting support and for raising the rlimit if
necessary [1]. But this was later reverted, because the probe would
sometimes fail, resulting in bpftool not being able to load all required
objects [2].
Here we add a more efficient probe, in bpftool itself. We first lower
the rlimit to 0, then we attempt to load a BPF object (and finally reset
the rlimit): if the load succeeds, then memcg-based memory accounting is
supported.
This approach was earlier proposed for the probe in libbpf itself [3],
but given that the library may be used in multithreaded applications,
the probe could have undesirable consequences if one thread attempts to
lock kernel memory while memlock rlimit is at 0. Since bpftool is
single-threaded and the rlimit is process-based, this is fine to do in
bpftool itself.
This probe was inspired by the similar one from the cilium/ebpf Go
library [4].
v2:
- Simply use sizeof(attr) instead of hardcoding a size via
offsetofend().
- Set r0 = 0 before returning in sample program.
[0] commit 97306be45fbe ("Merge branch 'switch to memcg-based memory
accounting'")
[1] commit a777e18f1bcd ("bpftool: Use libbpf 1.0 API mode instead of
RLIMIT_MEMLOCK")
[2] commit 6b4384ff1088 ("Revert "bpftool: Use libbpf 1.0 API mode
instead of RLIMIT_MEMLOCK"")
[3]
https://lore.kernel.org/bpf/20220609143614.97837-1-quentin@xxxxxxxxxxxxx/t/#u
[4] https://github.com/cilium/ebpf/blob/v0.9.0/rlimit/rlimit.go#L39
Cc: Stanislav Fomichev <sdf@xxxxxxxxxx>
Reviewed-by: Stanislav Fomichev <sdf@xxxxxxxxxx>
