summaryrefslogtreecommitdiffstats
path: root/crypto
diff options
context:
space:
mode:
authorAlexei Starovoitov <ast@fb.com>2016-08-05 23:01:27 +0200
committerDavid S. Miller <davem@davemloft.net>2016-08-07 02:49:19 +0200
commita6ed3ea65d9868fdf9eff84e6fe4f666b8d14b02 (patch)
treede7e1b8094593fe8717b1392dbe103eeec55c6be /crypto
parentnet: dsa: b53: Add missing ULL suffix for 64-bit constant (diff)
downloadlinux-a6ed3ea65d9868fdf9eff84e6fe4f666b8d14b02.tar.xz
linux-a6ed3ea65d9868fdf9eff84e6fe4f666b8d14b02.zip
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 'crypto')
0 files changed, 0 insertions, 0 deletions