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

[Masami Hiramatsu (Google)]

On Tue, 3 Nov 2026 12:11:47 +0100, Petr Mladek <pmladek@xxxxxxxx> wrote:
> On Tue 2026-11-03 11:06:06, Masami Hiramatsu (Google) wrote:
> > 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.)
> 
> We could export it if it would be useful for kprobes...

I also concern that exposing those means exposing internal implementation.
If so, I would like to avoid it, because if printk() becomes safe,
those simply become technical debt.

> 
> > > 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.
> 
> I do not have strong opinion here.
> 
> It just looks to me that using trace_printk() everywhere is an
> overkill. It is true that printk() is not safe when probing some
> locations, e.g. where a console is locked. But these are locations
> where you could not use printk() even in the probed code.

Ah, sorry if I caused a misunderstanding. What I meant was that for
callbacks — which might be invoked in critical contexts, such as those
used by kprobe or fprobe — we should use trace_printk() that include
recursion detection. This does not mean that trace_printk should be
used everywhere.

Thank you,

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