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