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

[John Ogness <john.ogness@linutronix.de>]

On 2026-10-17, Gabriele Monaco <gmonaco@redhat.com> wrote:
>> 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).

IMHO it would be a pity to lose support for ftrace/perf. I use these
tools extensively for my daily work evaluating real-time systems. Having
the rtapp RVmon integrated allows me to easily and naturally extend my
workflow to include rtapp violations. Plain stdout is hardly a
replacement for trace recordings that can be imported into existing
visualization and analysis tools.

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

I don't see the point of reinventing tools that already do the job
well. I do not mind if developers want to create their own tools that
provide some small subset of existing features. But I am concerned about
removing the in-kernel RV support for ftrace and perf.

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

That sounds like it could work. As long as there are kprobes in the call
stack of violations, I am happy.

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

A delayed kernel record is better than none. Although I really do not
see why it cannot simply call printk_deferred() directly. It is safe and
lockless. And it has the advantage of appropriate timestamping when
compared to any other printk's that may be happening at that time.

If we are already adding kfuncs for panics and violations, why the
resistance to printks?

John