Re: [RFC PATCH 00/20] rv: Add support for BPF monitors

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Fri Sep 4, 2026 at 9:53 PM PDT, Gabriele Monaco wrote:
>

Sorry for the delay.

> 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.

> 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.

> 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)

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.