diff options
author | Daniel Borkmann <daniel@iogearbox.net> | 2017-01-18 15:14:17 +0100 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2017-01-18 17:12:26 -0500 |
commit | d407bd25a204bd66b7346dde24bd3d37ef0e0b05 (patch) | |
tree | 01e49e08ca4f4eb258a2e2d9c67d03d503498696 /tools | |
parent | 9ed59592e3e379b2e9557dc1d9e9ec8fcbb33f16 (diff) | |
download | linux-d407bd25a204bd66b7346dde24bd3d37ef0e0b05.tar.gz linux-d407bd25a204bd66b7346dde24bd3d37ef0e0b05.tar.bz2 linux-d407bd25a204bd66b7346dde24bd3d37ef0e0b05.zip |
bpf: don't trigger OOM killer under pressure with map alloc
This patch adds two helpers, bpf_map_area_alloc() and bpf_map_area_free(),
that are to be used for map allocations. Using kmalloc() for very large
allocations can cause excessive work within the page allocator, so i) fall
back earlier to vmalloc() when the attempt is considered costly anyway,
and even more importantly ii) don't trigger OOM killer with any of the
allocators.
Since this is based on a user space request, for example, when creating
maps with element pre-allocation, we really want such requests to fail
instead of killing other user space processes.
Also, don't spam the kernel log with warnings should any of the allocations
fail under pressure. Given that, we can make backend selection in
bpf_map_area_alloc() generic, and convert all maps over to use this API
for spots with potentially large allocation requests.
Note, replacing the one kmalloc_array() is fine as overflow checks happen
earlier in htab_map_alloc(), since it must also protect the multiplication
for vmalloc() should kmalloc_array() fail.
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'tools')
0 files changed, 0 insertions, 0 deletions