Re: [RFC PATCH 00/20] rv: Add support for BPF monitors
From: Gabriele Monaco <gmonaco@redhat.com>
Date: 2026-09-15 07:15:45
Also in:
bpf, lkml
On Sat, 2026-09-12 at 18:26 -0700, Alexei Starovoitov wrote:
On Fri Sep 4, 2026 at 9:53 PM PDT, Gabriele Monaco wrote:quoted
Alexei, what I read from your opinion is: if you really want to do this RV thing, then you should just implement it all in BPF.yes.quoted
like the panic() one. Something BPF just shouldn't do, as I get it.There is a disconnect here. we have one KF_DESTRUCTIVE kfunc already. bpf_panic() can be another one. It will require CAP_SYS_BOOT.
Great, I have also been pointed to crash_kexec() [1] which seems to be doing already the same thing. Anyway this doesn't seem a blocker.
quoted
I'd rather discuss on what is the best approach /today/. And that's precisely why I submitted the talk for LPC.Excellent. We can start this discussion over email and continue at LPC. My understanding of RV is primitive, but from reading kernel/trace/rv/*.c it seems to me that it's a thin glue between tracepoints and monitors, a bit of boiler plate code via tracefs to enable monitors and seq file for visibility. What you're proposing is "yet another monitor" that is reusing this glue code, and that's my main objection. I don't see the value in kernel/trace/rv/*.c. (kernel/trace/rv/monitors/* are useful, of course)
I get it, essentially the point of contention here is that, besides loading tracing BPF programs (the event handlers), I'm /also/ loading a BPF struct_ops program to register the monitor to the existing in-kernel infrastructure. It is indeed not fully necessary to have BPF monitors share the same sysfs API, as they still need the userspace component to do useful monitoring.
What stops you from attaching tracing bpf progs to all tracepoints that you need, pinning few "bpf iterator" progs in bpffs that will provide text or binary output via seq files, run a state machine inside the prog, and do whatever "verification" logic inside them ? You don't need the rv/*.c glue. I see no need to introduce new bpf struct-ops api just to look-like-a-monitor from RV glue perspective. "runtime verification" as a concept makes sense, so focus on that.
I actually started my POC without struct_ops, activation happened by just triggering a dummy BPF program from userspace, but I'll look into these bpf iterators. Essentially sharing the API simplified how the userspace component handles some things and allowed to share reactors. But again, that's not necessarily the way. Thanks, Gabriele [1] - https://docs.ebpf.io/linux/kfuncs/crash_kexec