diff options
author | Martynas Pumputis <m@lambda.lt> | 2021-07-26 17:20:01 +0200 |
---|---|---|
committer | Andrii Nakryiko <andrii@kernel.org> | 2021-07-27 23:32:03 +0200 |
commit | 043c5bb3c4f43670ab4fea0b847373ab42d25f3e (patch) | |
tree | 3c30e15bb15e4a299305f1c0480695e0614e4326 /tools/testing/selftests/vm/transhuge-stress.c | |
parent | libbpf: Fix comment typo (diff) | |
download | linux-043c5bb3c4f43670ab4fea0b847373ab42d25f3e.tar.xz linux-043c5bb3c4f43670ab4fea0b847373ab42d25f3e.zip |
libbpf: Fix race when pinning maps in parallel
When loading in parallel multiple programs which use the same to-be
pinned map, it is possible that two instances of the loader will call
bpf_object__create_maps() at the same time. If the map doesn't exist
when both instances call bpf_object__reuse_map(), then one of the
instances will fail with EEXIST when calling bpf_map__pin().
Fix the race by retrying reusing a map if bpf_map__pin() returns
EEXIST. The fix is similar to the one in iproute2: e4c4685fd6e4 ("bpf:
Fix race condition with map pinning").
Before retrying the pinning, we don't do any special cleaning of an
internal map state. The closer code inspection revealed that it's not
required:
- bpf_object__create_map(): map->inner_map is destroyed after a
successful call, map->fd is closed if pinning fails.
- bpf_object__populate_internal_map(): created map elements is
destroyed upon close(map->fd).
- init_map_slots(): slots are freed after their initialization.
Signed-off-by: Martynas Pumputis <m@lambda.lt>
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Link: https://lore.kernel.org/bpf/20210726152001.34845-1-m@lambda.lt
Diffstat (limited to 'tools/testing/selftests/vm/transhuge-stress.c')
0 files changed, 0 insertions, 0 deletions