summaryrefslogtreecommitdiff
path: root/samples
diff options
context:
space:
mode:
authorAlexei Starovoitov <ast@fb.com>2016-08-06 00:01:27 +0300
committerDavid S. Miller <davem@davemloft.net>2016-08-07 03:49:19 +0300
commita6ed3ea65d9868fdf9eff84e6fe4f666b8d14b02 (patch)
treede7e1b8094593fe8717b1392dbe103eeec55c6be /samples
parent5e3b724e2767fb6495df1dcccaf7c79585c78ae9 (diff)
downloadlinux-a6ed3ea65d9868fdf9eff84e6fe4f666b8d14b02.tar.xz
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 'samples')
0 files changed, 0 insertions, 0 deletions