On Sat, Oct 17, 2026 at 05:23 PM John Ogness <[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. > 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.
