Bug 1837

Summary: another reentrancy crash
Product: systemtap Reporter: James Dickens <jamesd.wi>
Component: kprobesAssignee: 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
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.
Comment 1 Frank Ch. Eigler 2005-11-10 03:58:40 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).
Comment 2 Frank Ch. Eigler 2005-11-10 13:02:24 UTC
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.
Comment 3 Frank Ch. Eigler 2005-11-12 12:32:35 UTC

*** This bug has been marked as a duplicate of 1564 ***
Comment 4 Martin Hunt 2005-11-12 20:40:44 UTC
This has nothing to do with 1564. Translator cannot permit calls to printk (or
any other kernel functions) in safe mode.
Comment 5 Frank Ch. Eigler 2005-11-13 02:28:39 UTC
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.
Comment 6 Martin Hunt 2005-11-18 21:56:35 UTC
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.