diff options
author | Alexei Starovoitov <ast@fb.com> | 2016-08-05 14:01:27 -0700 |
---|---|---|
committer | David S. Miller <davem@davemloft.net> | 2016-08-06 20:49:19 -0400 |
commit | a6ed3ea65d9868fdf9eff84e6fe4f666b8d14b02 (patch) | |
tree | de7e1b8094593fe8717b1392dbe103eeec55c6be /lib/dynamic_debug.c | |
parent | 5e3b724e2767fb6495df1dcccaf7c79585c78ae9 (diff) | |
download | op-kernel-dev-a6ed3ea65d9868fdf9eff84e6fe4f666b8d14b02.zip op-kernel-dev-a6ed3ea65d9868fdf9eff84e6fe4f666b8d14b02.tar.gz |
bpf: restore behavior of bpf_map_update_elem
The introduction of pre-allocated hash elements inadvertently broke
the behavior of bpf hash maps where users expected to call
bpf_map_update_elem() without considering that the map can be full.
Some programs do:
old_value = bpf_map_lookup_elem(map, key);
if (old_value) {
... prepare new_value on stack ...
bpf_map_update_elem(map, key, new_value);
}
Before pre-alloc the update() for existing element would work even
in 'map full' condition. Restore this behavior.
The above program could have updated old_value in place instead of
update() which would be faster and most programs use that approach,
but sometimes the values are large and the programs use update()
helper to do atomic replacement of the element.
Note we cannot simply update element's value in-place like percpu
hash map does and have to allocate extra num_possible_cpu elements
and use this extra reserve when the map is full.
Fixes: 6c9059817432 ("bpf: pre-allocate hash map elements")
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'lib/dynamic_debug.c')
0 files changed, 0 insertions, 0 deletions