On 2026-10-17, "Alexei Starovoitov" <[email protected]> wrote: > On Sat, Oct 17, 2026 at 07:02 PM John Ogness <[email protected]> > 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
