[ Cc'ing John Ogness ]
On Mon, 2 Nov 2026 16:10:54 +0900 "Masami Hiramatsu (Google)" <[email protected]> wrote: > Hi, > > 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. John? -- Steve > > 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]/ > > Thank you, > --- > base-commit: bc71431221f5ba8bb33918399552636e059c2c45 > > Masami Hiramatsu (Google) (3): > samples/kprobes: Use trace_printk() in probe handlers > samples/fprobe: Use trace_printk() and trace_dump_stack() > docs: trace: Warn against using printk() in probe handlers > > > Documentation/trace/fprobe.rst | 5 +++ > Documentation/trace/kprobes.rst | 11 +++++- > samples/Kconfig | 4 +- > samples/fprobe/fprobe_example.c | 49 +++++-------------------- > samples/kprobes/kprobe_example.c | 69 > ++++++++++++++++++----------------- > samples/kprobes/kretprobe_example.c | 10 +++-- > 6 files changed, 66 insertions(+), 82 deletions(-) > > -- > Masami Hiramatsu (Google) <[email protected]>
