Re: [PATCH 0/3] probes: Use trace_printk() in probe handlers

[John Ogness <john.ogness@linutronix.de>]

[ Cc'ing Petr Mladek ]

On 2026-11-02, Steven Rostedt <rostedt@goodmis.org> wrote:
> [ Cc'ing John Ogness ]

Thanks.

>
> On Mon,  2 Nov 2026 16:10:54 +0900
> "Masami Hiramatsu (Google)" <mhiramat@kernel.org> wrote:
>> Here are patches to update the probe sample code to use trace_printk
>> instead of normal printk. Since the fprobe and kprobe/kretprobe handlers
>> can be called from somewhere where console is locked, using printk() is
>> basically unsafe. Only the unoptimized kprobe on x86 is safe because it
>> is ran with NMI context (in this case, the kernel uses printk_deferred()
>> automatically), but optimized kprobe/kretprobe/fprobe are not.
>
> I don't think printk() is unsafe in these situations anymore.

Since we still support legacy consoles, it is true that printk() is not
safe in these contexts when a legacy console is registered.

However, the printk_deferred() variant _is_ safe from any context. Once
we convert the legacy consoles (including boot consoles) to nbcon,
printk_deferred() can become printk() and still be safe from any
context.

It is misfortunate to add documentation saying printk() is not safe,
since the problem is converting the remaining legacy consoles. But we
can cleanup all such documentation later once the legacy consoles are
gone.

John

>> Thus, this series replaces those printk() (pr_*()) with trace_printk()
>> which should be safe to output the result into trace buffer, and use
>> trace_dump_stack() instead of stack_trace_print().
>> 
>> The similar issue had been reported by Tiezhu Yang [1] in 2023, but
>> it was pointed different reason, and not applicable to upstream.
>> I investigated it again.
>> 
>> [1] https://lore.kernel.org/all/d179086d-78d8-d0e3-e113-9072cffa55f4@loongson.cn/