On Mon, Oct 19, 2026 at 11:34 AM John Ogness <[email protected]> wrote:
>
> For production environments, I expect that trace_printk's are only
> occurring for violations, in which case the cost of a string compare
> will probably be irrelevant.
>
> Are these trace_printk's available without getting the scary kernel
> warning when kernel code uses trace_printk()? We do want RV support to
> be enabled in production kernels.
>
> John
>
Since commit ac5a72ea5c89 ("bpf: Use dedicated bpf_trace_printk event
instead of trace_printk()"), bpf_trace_printk() does not use
trace_printk(). Rather, it is recorded as a separate ftrace event that
has to be enabled, in
/sys/kernel/tracing/events/bpf_trace/bpf_trace_printk, for each
instance that wants to trace it, and using it does not print any
warnings into dmesg.
The BPF documentation says otherwise [1]:
"bpf_trace_printk() is slow, and should only be used for debugging
purposes. For this reason, a notice block (spanning several lines) is
printed to kernel logs and states that the helper should not be used
"for production use" the first time this helper is used (or more
precisely, when trace_printk() buffers are allocated). For passing
values to user space, perf events should be preferred."
[1] https://docs.ebpf.io/linux/helper-function/bpf_trace_printk/
but that is clearly outdated.
Tomas
