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

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

On 2026-10-16, "Alexei Starovoitov" <alexei.starovoitov@gmail.com> wrote:
> On Thu, Oct 08, 2026 at 11:54 AM Gabriele Monaco <gmonaco@redhat.com> wrote:
>> Reactors in this patch use bpf_printk(), which is in fact a trace_printk()
>> instead of a real printk, is there a technical limitation forbidding us to
>> create a kfunc using some flavour of printk_deferred()? Or am I missing an
>> existing one? (this need was brought up by John, Cc'd here)
>
> No technical limitation, and there is no such kfunc today.
> printk_deferred() is a lockless store into the ring buffer plus irq_work.
> It's ok in any context where tracing progs run.
> The closest we have is bpf_stream_vprintk(). That's stdout/stderr of
> the prog. User space has to read it.
> rv tool is around for as long as the monitor is loaded, so it can read
> the stream and log it anywhere like /dev/kmsg.
> If the message has to reach the console when user space cannot run
> then the kfunc makes sense, but using bpf_stream is imo much cleaner.

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.

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?

John Ogness