First start this script
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.
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