summaryrefslogtreecommitdiffstats
path: root/tools/lib/bpf/bpf.h
diff options
context:
space:
mode:
authorAndrii Nakryiko <andrii@kernel.org>2021-12-14 20:59:03 +0100
committerDaniel Borkmann <daniel@iogearbox.net>2021-12-14 22:16:45 +0100
commite542f2c4cd16d49392abf3349341d58153d3c603 (patch)
tree92d3513488c9c10079f5bff3db8541d2b194e02a /tools/lib/bpf/bpf.h
parentlibbpf: Add sane strncpy alternative and use it internally (diff)
downloadlinux-e542f2c4cd16d49392abf3349341d58153d3c603.tar.xz
linux-e542f2c4cd16d49392abf3349341d58153d3c603.zip
libbpf: Auto-bump RLIMIT_MEMLOCK if kernel needs it for BPF
The need to increase RLIMIT_MEMLOCK to do anything useful with BPF is one of the first extremely frustrating gotchas that all new BPF users go through and in some cases have to learn it a very hard way. Luckily, starting with upstream Linux kernel version 5.11, BPF subsystem dropped the dependency on memlock and uses memcg-based memory accounting instead. Unfortunately, detecting memcg-based BPF memory accounting is far from trivial (as can be evidenced by this patch), so in practice most BPF applications still do unconditional RLIMIT_MEMLOCK increase. As we move towards libbpf 1.0, it would be good to allow users to forget about RLIMIT_MEMLOCK vs memcg and let libbpf do the sensible adjustment automatically. This patch paves the way forward in this matter. Libbpf will do feature detection of memcg-based accounting, and if detected, will do nothing. But if the kernel is too old, just like BCC, libbpf will automatically increase RLIMIT_MEMLOCK on behalf of user application ([0]). As this is technically a breaking change, during the transition period applications have to opt into libbpf 1.0 mode by setting LIBBPF_STRICT_AUTO_RLIMIT_MEMLOCK bit when calling libbpf_set_strict_mode(). Libbpf allows to control the exact amount of set RLIMIT_MEMLOCK limit with libbpf_set_memlock_rlim_max() API. Passing 0 will make libbpf do nothing with RLIMIT_MEMLOCK. libbpf_set_memlock_rlim_max() has to be called before the first bpf_prog_load(), bpf_btf_load(), or bpf_object__load() call, otherwise it has no effect and will return -EBUSY. [0] Closes: https://github.com/libbpf/libbpf/issues/369 Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Signed-off-by: Daniel Borkmann <daniel@iogearbox.net> Link: https://lore.kernel.org/bpf/20211214195904.1785155-2-andrii@kernel.org
Diffstat (limited to 'tools/lib/bpf/bpf.h')
-rw-r--r--tools/lib/bpf/bpf.h2
1 files changed, 2 insertions, 0 deletions
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 94e553a0ff9d..00619f64a040 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -35,6 +35,8 @@
extern "C" {
#endif
+int libbpf_set_memlock_rlim(size_t memlock_bytes);
+
struct bpf_map_create_opts {
size_t sz; /* size of this struct for forward/backward compatibility */