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

[Masami Hiramatsu (Google)]

On Mon, 02 Nov 2026 23:07:41 +0106, John Ogness <john.ogness@xxxxxxxxxxxxx> wrote:
> [ Cc'ing Petr Mladek ]
> 
> On 2026-11-02, Steven Rostedt <rostedt@xxxxxxxxxxx> wrote:
> > [ Cc'ing John Ogness ]
> 
> Thanks.
> 
> >
> > On Mon,  2 Nov 2026 16:10:54 +0900
> > "Masami Hiramatsu (Google)" <mhiramat@xxxxxxxxxx> 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.

Got it. But since printk_deferred() is not exposed to modules,
these sample modules can not use it. (printk_deferred_enter/exit()
are also not exposed.)

> 
> 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.

So, until it is done, this series is valid. Please let me know it.
After that version, I can revert these.

Thanks,

> 
> 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@xxxxxxxxxxx/
>

-- 
Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>