• Quentin Monnet's avatar
    Revert "bpftool: Use libbpf 1.0 API mode instead of RLIMIT_MEMLOCK" · 6b4384ff
    Quentin Monnet authored
    This reverts commit a777e18f.
    
    In commit a777e18f ("bpftool: Use libbpf 1.0 API mode instead of
    RLIMIT_MEMLOCK"), we removed the rlimit bump in bpftool, because the
    kernel has switched to memcg-based memory accounting. Thanks to the
    LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK, we attempted to keep compatibility
    with other systems and ask libbpf to raise the limit for us if
    necessary.
    
    How do we know if memcg-based accounting is supported? There is a probe
    in libbpf to check this. But this probe currently relies on the
    availability of a given BPF helper, bpf_ktime_get_coarse_ns(), which
    landed in the same kernel version as the memory accounting change. This
    works in the generic case, but it may fail, for example, if the helper
    function has been backported to an older kernel. This has been observed
    for Google Cloud's Container-Optimized OS (COS), where the helper is
    available but rlimit is still in use. The probe succeeds, the rlimit is
    not raised, and probing features with bpftool, for example, fails.
    
    A patch was submitted [0] to update this probe in libbpf, based on what
    the cilium/ebpf Go library does [1]. It would lower the soft rlimit to
    0, attempt to load a BPF object, and reset the rlimit. But it may induce
    some hard-to-debug flakiness if another process starts, or the current
    application is killed, while the rlimit is reduced, and the approach was
    discarded.
    
    As a workaround to ensure that the rlimit bump does not depend on the
    availability of a given helper, we restore the unconditional rlimit bump
    in bpftool for now.
    
      [0] https://lore.kernel.org/bpf/20220609143614.97837-1-quentin@isovalent.com/
      [1] https://github.com/cilium/ebpf/blob/v0.9.0/rlimit/rlimit.go#L39Signed-off-by: default avatarQuentin Monnet <quentin@isovalent.com>
    Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
    Cc: Yafang Shao <laoar.shao@gmail.com>
    Cc: Stanislav Fomichev <sdf@google.com>
    Link: https://lore.kernel.org/bpf/20220610112648.29695-2-quentin@isovalent.com
    6b4384ff
main.c 11.2 KB