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

[Petr Mladek <pmladek@suse.com>]

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@linutronix.de> wrote:
> > [ 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.
> 
> 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...

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

I believe that trace_printk() has a similar problem. You could
not use it inside the code used by trace_printk() because
it might cause an unbound recursion.

I agree that the scope of the code used by trace_printk() is
smaller than the code used by console drivers. Also it is better
located. And maybe, the recursion can be even detected and handled.

But still, the point is that even trace_printk() is not a 100%
safe cure. So, maybe, instead of proposing trace_printk() everywhere,
it might be enough to propose it only for probing the printk/console
related code. Well, I know that it involves also some less obvious
areas, for example, irq_work, some timer and scheduler code.

That said, I do not want to block this patchset. It is solving
some real problems...

Best Regards,
Petr