bpf: Introduce task_vma open-coded iterator kfuncs
authorDave Marchevsky <davemarchevsky@fb.com>
Fri, 13 Oct 2023 20:44:24 +0000 (13:44 -0700)
committerAndrii Nakryiko <andrii@kernel.org>
Fri, 13 Oct 2023 22:48:58 +0000 (15:48 -0700)
commit4ac4546821584736798aaa9e97da9f6eaf689ea3
treeafa500eeb71da22784f72b1caa74a3b47dc35319
parent45b38941c81f16bb2e9b0115f03e164a3576ea8b
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
kernel/bpf/helpers.c
kernel/bpf/task_iter.c