Summary: | another reentrancy crash | ||
---|---|---|---|
Product: | systemtap | Reporter: | James Dickens <jamesd.wi> |
Component: | kprobes | Assignee: | Martin Hunt <hunt> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | P2 | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Host: | Target: | ||
Build: | Last reconfirmed: |
Description
James Dickens
2005-11-10 03:38:27 UTC
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. |