summary refs log tree commit diff
path: root/mm/page_alloc.c
diff options
context:
space:
mode:
authorAndrii Nakryiko <andrii@kernel.org>2020-12-23 12:06:52 -0800
committerDaniel Borkmann <daniel@iogearbox.net>2020-12-24 01:35:46 +0100
commit11b844b0b7c7c3dc8e8f4d0bbaad5e798351862c (patch)
tree91c0274f47f51b4f94bde30281d421c312b6188a /mm/page_alloc.c
parente7e518053c267bb6be3799520d9f4a34c7264a2e (diff)
downloadlinux-11b844b0b7c7c3dc8e8f4d0bbaad5e798351862c.tar.gz
selftests/bpf: Work-around EBUSY errors from hashmap update/delete
20b6cc34ea74 ("bpf: Avoid hashtab deadlock with map_locked") introduced
a possibility of getting EBUSY error on lock contention, which seems to happen
very deterministically in test_maps when running 1024 threads on low-CPU
machine. In libbpf CI case, it's a 2 CPU VM and it's hitting this 100% of the
time. Work around by retrying on EBUSY (and EAGAIN, while we are at it) after
a small sleep. sched_yield() is too agressive and fails even after 20 retries,
so I went with usleep(1) for backoff.

Also log actual error returned to make it easier to see what's going on.

Fixes: 20b6cc34ea74 ("bpf: Avoid hashtab deadlock with map_locked")
Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Song Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20201223200652.3417075-1-andrii@kernel.org
Diffstat (limited to 'mm/page_alloc.c')
0 files changed, 0 insertions, 0 deletions