diff options
author | Quentin Monnet <quentin.monnet@netronome.com> | 2018-11-07 12:29:30 +0000 |
---|---|---|
committer | Daniel Borkmann <daniel@iogearbox.net> | 2018-11-07 22:22:21 +0100 |
commit | 8302b9bd31d29f29dd24dd6b1e1e5682c302c11c (patch) | |
tree | 3c6361d5b6c519f624fb773af22bb4230ecf7633 /drivers/ide/via82cxxx.c | |
parent | selftests/bpf: enable (uncomment) all tests in test_libbpf.sh (diff) | |
download | linux-dev-8302b9bd31d29f29dd24dd6b1e1e5682c302c11c.tar.xz linux-dev-8302b9bd31d29f29dd24dd6b1e1e5682c302c11c.zip |
tools: bpftool: adjust rlimit RLIMIT_MEMLOCK when loading programs, maps
The limit for memory locked in the kernel by a process is usually set to
64 kbytes by default. This can be an issue when creating large BPF maps
and/or loading many programs. A workaround is to raise this limit for
the current process before trying to create a new BPF map. Changing the
hard limit requires the CAP_SYS_RESOURCE and can usually only be done by
root user (for non-root users, a call to setrlimit fails (and sets
errno) and the program simply goes on with its rlimit unchanged).
There is no API to get the current amount of memory locked for a user,
therefore we cannot raise the limit only when required. One solution,
used by bcc, is to try to create the map, and on getting a EPERM error,
raising the limit to infinity before giving another try. Another
approach, used in iproute2, is to raise the limit in all cases, before
trying to create the map.
Here we do the same as in iproute2: the rlimit is raised to infinity
before trying to load programs or to create maps with bpftool.
Signed-off-by: Quentin Monnet <quentin.monnet@netronome.com>
Reviewed-by: Jakub Kicinski <jakub.kicinski@netronome.com>
Acked-by: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Diffstat (limited to 'drivers/ide/via82cxxx.c')
0 files changed, 0 insertions, 0 deletions