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

[Gabriele Monaco <gmonaco@redhat.com>]

Il 16 ottobre 2026 19:20:33 UTC, John Ogness <john.ogness@linutronix.de> ha scritto:
>
>I am still not clear how the rv tool will replace the existing in-kernel
>implementation. Right now violations call printk(), which conveniently
>show up in kernel logs and consoles. More importantly, there are the
>rtapp violation events, which makes it very easy to use ftrace and perf
>features to record traces, take actions, generate statistics, and dump
>backtraces on violations.

The plan is to keep everything you'd now do with perf/ftrace as plain stdout of the RV tool. Right now you can see the same ftrace output using rv mon <monitor> -t for in-kernel monitors (only deterministic automata).

We are missing stack traces (which I'd optionally add only on errors) and perhaps other events (e.g. the -e in either tool if you aren't only interested in errors/events of the monitor).

Anything else you may want to do passes through reactors (e.g. printk/panic or others). See more later.

>Is it planned to pull all this out of the kernel but then somehow the rv
>tool allows ftrace, perf, and console to continue to work with
>violations? (For example, by somehow defining kprobes for violations and
>writing violation information to /dev/kmsg?) Or is the rv tool supposed
>to provide its own DIY variant of these features?

My plan isn't particularly strict right now. I'm aiming to allow BPF monitors in the user space tool as an exploratory effort.
I don't think you would easily interact with ftrace/perf from those though.

If that's a requirement, you could probably call a kfunc from BPF and attach a kprobe there. I would implement that from a reactor (violations only).

For a pure printk reactor, I drafted an implementation that calls directly printk_deferred(), Alexei is suggesting to write to /dev/kmsg from user space what BPF passes.
Since you were the one suggesting having a real printk, would your use-case favour either solution? I'd expect some different latency if the log passes from BPF to /dev/kmsg , but I'm not sure that's an issue for you.

Gabriele