diff options
| author | Martin KaFai Lau <[email protected]> | 2022-09-01 19:11:45 +0000 |
|---|---|---|
| committer | Martin KaFai Lau <[email protected]> | 2022-09-01 19:16:23 +0000 |
| commit | 23d86c8e02e55e511cd37e7ef2280a0030750954 (patch) | |
| tree | 9e9824013d4e2ac7974944f22f2f90dfab154814 /tools/testing/selftests/bpf/prog_tests/global_data_init.c | |
| parent | Merge branch 'fixes for concurrent htab updates' (diff) | |
| parent | selftests/bpf: Test concurrent updates on bpf_task_storage_busy (diff) | |
| download | kernel-23d86c8e02e55e511cd37e7ef2280a0030750954.tar.gz kernel-23d86c8e02e55e511cd37e7ef2280a0030750954.zip | |
Merge branch 'Use this_cpu_xxx for preemption-safety'
Hou Tao says:
====================
From: Hou Tao <[email protected]>
Hi,
The patchset aims to make the update of per-cpu prog->active and per-cpu
bpf_task_storage_busy being preemption-safe. The problem is on same
architectures (e.g. arm64), __this_cpu_{inc|dec|inc_return} are neither
preemption-safe nor IRQ-safe, so under fully preemptible kernel the
concurrent updates on these per-cpu variables may be interleaved and the
final values of these variables may be not zero.
Patch 1 & 2 use the preemption-safe per-cpu helpers to manipulate
prog->active and bpf_task_storage_busy. Patch 3 & 4 add a test case in
map_tests to show the concurrent updates on the per-cpu
bpf_task_storage_busy by using __this_cpu_{inc|dec} are not atomic.
Comments are always welcome.
Regards,
Tao
Change Log:
v2:
* Patch 1: update commit message to indicate the problem is only
possible for fully preemptible kernel
* Patch 2: a new patch which fixes the problem for prog->active
* Patch 3 & 4: move it to test_maps and make it depend on CONFIG_PREEMPT
v1: https://lore.kernel.org/bpf/[email protected]/
====================
Signed-off-by: Martin KaFai Lau <[email protected]>
Diffstat (limited to 'tools/testing/selftests/bpf/prog_tests/global_data_init.c')
0 files changed, 0 insertions, 0 deletions