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

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

On 2026-10-17, "Alexei Starovoitov" <alexei.starovoitov@gmail.com> 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.

It would be nice if it could be filtered so that only RV violation
bpf_printk's would trigger. I do not think it is possible for a filter
to do primitive pattern matching on @bpf_string. Or am I wrong?

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

With the "new" ringbuffer and nbcon implementations, it no longer dos-es
the kernel, so I have no problem with bpf programs calling
printk_deferred(). And besides, userspace can already blast the
ringbuffer and consoles via /dev/kmsg.

John