On 2026-10-16, "Alexei Starovoitov" <[email protected]> wrote: > On Thu, Oct 08, 2026 at 11:54 AM Gabriele Monaco <[email protected]> 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
