aboutsummaryrefslogtreecommitdiff
path: root/tools/testing/selftests/bpf/progs/percpu_alloc_array.c
diff options
context:
space:
mode:
authorDave Marchevsky <davemarchevsky@fb.com>2023-10-13 13:44:24 -0700
committerAndrii Nakryiko <andrii@kernel.org>2023-10-13 15:48:58 -0700
commit4ac4546821584736798aaa9e97da9f6eaf689ea3 (patch)
treeafa500eeb71da22784f72b1caa74a3b47dc35319 /tools/testing/selftests/bpf/progs/percpu_alloc_array.c
parent45b38941c81f16bb2e9b0115f03e164a3576ea8b (diff)
bpf: Introduce task_vma open-coded iterator kfuncs
This patch adds kfuncs bpf_iter_task_vma_{new,next,destroy} which allow creation and manipulation of struct bpf_iter_task_vma in open-coded iterator style. BPF programs can use these kfuncs directly or through bpf_for_each macro for natural-looking iteration of all task vmas. The implementation borrows heavily from bpf_find_vma helper's locking - differing only in that it holds the mmap_read lock for all iterations while the helper only executes its provided callback on a maximum of 1 vma. Aside from locking, struct vma_iterator and vma_next do all the heavy lifting. A pointer to an inner data struct, struct bpf_iter_task_vma_data, is the only field in struct bpf_iter_task_vma. This is because the inner data struct contains a struct vma_iterator (not ptr), whose size is likely to change under us. If bpf_iter_task_vma_kern contained vma_iterator directly such a change would require change in opaque bpf_iter_task_vma struct's size. So better to allocate vma_iterator using BPF allocator, and since that alloc must already succeed, might as well allocate all iter fields, thereby freezing struct bpf_iter_task_vma size. Signed-off-by: Dave Marchevsky <davemarchevsky@fb.com> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Andrii Nakryiko <andrii@kernel.org> Link: https://lore.kernel.org/bpf/20231013204426.1074286-4-davemarchevsky@fb.com
Diffstat (limited to 'tools/testing/selftests/bpf/progs/percpu_alloc_array.c')
0 files changed, 0 insertions, 0 deletions