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

On Sat, Oct 17, 2026 at 05:23 PM John Ogness [off-list ref] wrote:

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

No need for a kfunc to get that.
bpf_printk() in the reactor is a regular bpf_trace:bpf_trace_printk
event, fired from the prog where the violation is detected.
ftrace triggers and perf can attach to it.

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?

printk kfunc wouldn't be limited to rv. Any tracing prog would
be able to write to dmesg with no rate limit and then you, Petr
and others will start yelling that bpf is abusing printk
and dos-ing the rest of the kernel.
Hence let's avoid this can of worms.