summaryrefslogtreecommitdiff
path: root/kernel/workqueue.c
diff options
context:
space:
mode:
authorMartynas Pumputis <m@lambda.lt>2021-07-26 17:20:01 +0200
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2021-09-18 13:40:23 +0200
commit4af60a543ba60239d8931215c7e239c91e42c129 (patch)
treeb044028c0588e8d640f7c09863b1692d52e7e7b0 /kernel/workqueue.c
parent874d5aa06ce2aac1085d3bf2868b0bc57afd5856 (diff)
libbpf: Fix race when pinning maps in parallel
[ Upstream commit 043c5bb3c4f43670ab4fea0b847373ab42d25f3e ] 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 Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'kernel/workqueue.c')
0 files changed, 0 insertions, 0 deletions