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:
> On Sat, Oct 17, 2026 at 07:02 PM John Ogness <john.ogness@linutronix.de> wrote:
>> 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?
>
> not an ftrace expert, but it should be possible. bpf_string is
> a dynamic string field and filters take globs on those.

Yes, indeed this works. Thanks for mentioning the globs.

>> 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.
>
> well, /dev/kmsg is ratelimited unless printk.devkmsg=on,
> but the kfunc wouldn't be.
> I still feel that bpf_stream + user space that writes into
> /dev/kmsg is a better design.

My issue with the /dev/kmsg design is bogus timestamps. But let's just
drop my suggestion to allow eBPF programs to call printk(). Since the RV
move to eBPF will require new user workflows anyway, the users will need
to learn these new packages, tools, and output sources. The important
thing (for me) is RV violations can still be used effectively with
ftrace/perf, which they can (using globs in bpf_trace:bpf_trace_printk
filters).

@gmonaco: There should be clean glob-friendly RV bpf_trace_printk
strings so that filters can be easily and reliably set up.

John