A quick bisect against groovy shows:
dd773889e74605c1a0a97d701f589733800c9dc8 is the first bad commit
commit dd773889e74605c1a0a97d701f589733800c9dc8
Author: David Verbeiren <email address hidden>
Date: Wed Nov 4 12:23:32 2020 +0100
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.
A quick bisect against groovy shows: 1a0a97d701f5897 33800c9dc8 is the first bad commit 1a0a97d701f5897 33800c9dc8
dd773889e74605c
commit dd773889e74605c
Author: David Verbeiren <email address hidden>
Date: Wed Nov 4 12:23:32 2020 +0100
bpf: Zero-fill re-used per-cpu map element
BugLink: https:/ /bugs.launchpad .net/bugs/ 1908555
[ Upstream commit d3bec0138bfbe58 606fc1d6f57a4cd c1a20218db ]
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 update_ elem(), the bpf program can
map, then deletes some (or userspace does). When later adding
new elements using bpf_map_
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 <email address hidden>
Signed-off-by: Alexei Starovoitov <email address hidden>
Acked-by: Matthieu Baerts <email address hidden>
Acked-by: Andrii Nakryiko <email address hidden>
Link: https://<email address hidden>
Signed-off-by: Sasha Levin <email address hidden>
Signed-off-by: Kamal Mostafa <email address hidden>
Signed-off-by: Ian May <email address hidden>
kernel/ bpf/hashtab. c | 30 ++- testing/ selftests/ bpf/prog_ tests/map_ init.c | 214 +++++++ +++++++ +++++++ + testing/ selftests/ bpf/progs/ test_map_ init.c | 33 ++++ selftests/ bpf/prog_ tests/map_ init.c selftests/ bpf/progs/ test_map_ init.c
tools/
tools/
3 files changed, 275 insertions(+), 2 deletions(-)
create mode 100644 tools/testing/
create mode 100644 tools/testing/
$ git tag --contains dd773889e74605c 1a0a97d701f5897 33800c9dc8
Ubuntu-5.8.0-44.50
Ubuntu-5.8.0-45.51