Re: [PATCH v2 10/15] tools/rv: Add BPF monitors

[Alexei Starovoitov]

On Thu, Oct 01, 2026 at 05:20 PM Gabriele Monaco <gmonaco@xxxxxxxxxx> wrote:

Overall looks much better.
Some of the code reimplements bpftool, but it's user space.
It can be cleaned up later.

> +$(BPF_DIR)/%.o: $(BPF_DIR)/%.c $(VMLINUX_H)
> +	$(QUIET_CLANG)$(CLANG) $(BPF_CFLAGS) -c $< -o $@
> +	$(Q)$(LLVM_STRIP) -g $@
> +	$(Q)$(LLVM_OBJCOPY) --remove-section=.rel.rodata $@

What is this for?
Released libbpf ignores it with "skipping relo section" message.
Removing the section only hides that some pointer in .rodata is left
without relocation. What is it?
libbpf in bpf-next needs .rel.rodata to resolve pointers to functions.
See commit b223044a68d5 ("libbpf: Resolve pointers to functions in
read-only data").

> +struct {
> +	__uint(type, BPF_MAP_TYPE_HASH);
> +	__uint(max_entries, 10240);
> +	__type(key, da_id_type);
> +	__type(value, struct da_monitor_storage_bpf);
> +} rv_mon_map SEC(".maps");

Why hash by pid?
Use BPF_MAP_TYPE_TASK_STORAGE for per-task monitors.
Once there are 10240 tasks bpf_map_update_elem() in da_create_storage()
fails, the error is ignored, and the rest of the tasks are silently
not monitored.
Task storage is freed with the task. No need for handle_obj_cleanup,
id, target and PF_EXITING.

pw-bot: cr