On 2026-10-17, "Alexei Starovoitov" <[email protected]> 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
