Re: [PATCH bpf-next v2] bpftool: Probe for memcg-based accounting before bumping rlimit

[sdf@google.com]

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@isovalent.com/t/#u
> [4] https://github.com/cilium/ebpf/blob/v0.9.0/rlimit/rlimit.go#L39

> Cc: Stanislav Fomichev <sdf@google.com>

Reviewed-by: Stanislav Fomichev <sdf@google.com>