First start this script probe kernel.function("vscnprintf") { printk("in vscnprintf..."); } To trigger the bug execute any printk statement. This can easily be triggered by any problem in the kernel, or course you can trigger it manually by running the following in a separate Systemtap script. probe begin { printk("in begin..."); exit(); } stap -V SystemTap translator/driver (version 0.4.2 built 2005-10-31) Copyright (C) 2005 Red Hat, Inc. and others This is free software; see the source for copying conditions.
This is a known class of bugs related to kprobes/runtime reentrancy. For others, see bug #1813 and especially bug #1564. In this case, on the RHEL4U2 kernel, I can see a kernel panic, induced by a script-invoked printk attempting to take a spin lock that it's already holding (from before the vscnprintf kprobe hit).
A plausible "safety test" for passing script-level printk to kernel printk may be in_interrupt(), by the fortunate coincidence that printk uses spin_lock_irqsave around its critical section.
*** This bug has been marked as a duplicate of 1564 ***
This has nothing to do with 1564. Translator cannot permit calls to printk (or any other kernel functions) in safe mode.
What do you mean? "safe mode" does not apply as a distinction amongst functions in the tapsets / runtime. "printk" is just a special case of I/O that needs to use probe-context-safe mechanism. If you still think this is distinct from bug #1564, please elaborate.
printk has always been unsafe and needed replacement/removal. However it was there to support this initial phase of development. It seems the debate was between writing a systemtap-safe printk and just removing it. At the meeting, no one indicated a need for printk so it is therefore eliminated.