]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
bpf: Zero-fill re-used per-cpu map element
authorDavid Verbeiren <david.verbeiren@tessares.net>
Wed, 4 Nov 2020 11:23:32 +0000 (12:23 +0100)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Wed, 18 Nov 2020 18:22:18 +0000 (19:22 +0100)
commitab68b940dd6f7b5f8e2557937162dcb8a0583a05
tree12601ee597d8a62aeb885e5280af58016991b5f9
parent457e9f9333a1f313dd63b128690a56a7eaa3a70e
bpf: Zero-fill re-used per-cpu map element

[ Upstream commit d3bec0138bfbe58606fc1d6f57a4cdc1a20218db ]

Zero-fill element values for all other cpus than current, just as
when not using prealloc. This is the only way the bpf program can
ensure known initial values for all cpus ('onallcpus' cannot be
set when coming from the bpf program).

The scenario is: bpf program inserts some elements in a per-cpu
map, then deletes some (or userspace does). When later adding
new elements using bpf_map_update_elem(), the bpf program can
only set the value of the new elements for the current cpu.
When prealloc is enabled, previously deleted elements are re-used.
Without the fix, values for other cpus remain whatever they were
when the re-used entry was previously freed.

A selftest is added to validate correct operation in above
scenario as well as in case of LRU per-cpu map element re-use.

Fixes: 6c9059817432 ("bpf: pre-allocate hash map elements")
Signed-off-by: David Verbeiren <david.verbeiren@tessares.net>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20201104112332.15191-1-david.verbeiren@tessares.net
Signed-off-by: Sasha Levin <sashal@kernel.org>
kernel/bpf/hashtab.c
tools/testing/selftests/bpf/prog_tests/map_init.c [new file with mode: 0644]
tools/testing/selftests/bpf/progs/test_map_init.c [new file with mode: 0644]