On 7/14/25 10:45 AM, Leo Yan wrote:
Hi Yonghong,
Really sorry for the long delay. Now I am restarting this work.
On Mon, Dec 16, 2024 at 09:21:15AM -0800, Yonghong Song wrote:
On 12/15/24 11:34 AM, Leo Yan wrote:
The bpf_perf_event_aux_pause kfunc will be used to control the Perf AUX
area to pause or resume.
An example use-case is attaching eBPF to Ftrace tracepoints. When a
tracepoint is hit, the associated eBPF program will be executed. The
eBPF program can invoke bpf_perf_event_aux_pause() to pause or resume
AUX trace. This is useful for fine-grained tracing by combining
Perf and eBPF.
This commit implements the bpf_perf_event_aux_pause kfunc, and make it
pass the eBPF verifier.
The subject and commit message mentions to implement a kfunc,
but actually you implemented a uapi helper. Please implement a kfunc
instead (searching __bpf_kfunc in kernel/bpf directory).
After some research, my understanding is that kfunc is flexible for
exposing APIs via BTF, whereas BPF_CALL is typically used for core BPF
features - such as accessing BPF maps.
Coming back to this patch: it exposes a function with the following
definition:
int bpf_perf_event_aux_pause(struct bpf_map *map, u64 flags, u32 pause);
I'm not certain whether using __bpf_kfunc is appropriate here, or if I
should stick to BPF_CALL to ensure support for accessing bpf_map
pointers?
Using helpers (BPF_CALL) is not an option as the whole bpf ecosystem
moves to kfunc mechanism. You can certainly use kfunc with 'struct bpf_map *'
as the argument. For example the following kfunc:
__bpf_kfunc s64 bpf_map_sum_elem_count(const struct bpf_map *map)
in kernel/bpf/map_iter.c
Thanks,
Leo
