diff options
author | Andrii Nakryiko <andrii@kernel.org> | 2020-12-23 12:06:52 -0800 |
---|---|---|
committer | Daniel Borkmann <daniel@iogearbox.net> | 2020-12-24 01:35:46 +0100 |
commit | 11b844b0b7c7c3dc8e8f4d0bbaad5e798351862c (patch) | |
tree | 91c0274f47f51b4f94bde30281d421c312b6188a /kernel | |
parent | e7e518053c267bb6be3799520d9f4a34c7264a2e (diff) | |
download | linux-11b844b0b7c7c3dc8e8f4d0bbaad5e798351862c.tar.gz linux-11b844b0b7c7c3dc8e8f4d0bbaad5e798351862c.tar.bz2 linux-11b844b0b7c7c3dc8e8f4d0bbaad5e798351862c.zip |
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 'kernel')
0 files changed, 0 insertions, 0 deletions