3 bugs found.

[bibo,mao]

When running these three test cases, system also hanged up on my ia32 machine,
and my kernel version is latest git kernel.

David Smith wrote:
> James Dickens wrote:
>  > Here are 3 scripts, one line each, they each break the Systemtap one
>  > is old, just needs to expand the current bug report.
>  >
>  > Linux localhost.localdomain 2.6.17-1.2187_FC5 #1 Mon Sep 11 01:17:06
>  > EDT 2006 i686 athlon i386 GNU/Linux
> 
> Since I've got a similar system (except mine isn't an athlon), I decided
> to take a look at these.  See stuff below.
> 
>  > Latest cvs updates as of 2  hours ago.
>  >
>  > Distro: Fedora FC5
>  >
>  > Stack fault on the cpu. Halting the machine, This is x86 previously
>  > only filed for x86_64
>  >
>  > probe kernel.function("*") { print(".") }
>  >
>  > To narrow it down a bit, this causes the same stack fault
>  >
>  > probe kernel.function("*@kernel/*") { printf("here\n"); }
> 
> I've narrowed this one down.  This only happens when probing
> 'atomic_notifier_call_chain'.
If there is recursive kprobe, the reenter kprobe hanlder path will include 
atomic_notifier_call_chain function, that will cause numerous recursive kprobe.
In kernel side this function should be labeled with prefix __kprobe.

>  > This one produces an oops, I can post the end of it, if nobudy else
>  > can reproduce that has a serial console.
>  >
>  > probe kernel.function("*@kernel/spinlock.c") { printf("."); }
> 
> I've reproduced this one with '_spin_unlock_irqrestore'.  On the console
> I get:
> 
> BUG: spinlock lockup on CPU#0
In file runtime/transport/procfs.c of systemtap package, two function both call
spin_lock_irqsave function, these two function are _stp_write and 
_stp_proc_read_cmd. If any function or code between spin_lock_irqsave and 
spin_unlock_irqrestore of _stp_proc_read_cmd is probed, there will be possible
deadlock, because probe handler will call _stp_write function. 

On kernel side if kretprobe address falls between 
spin_lock_irqsave/spin_unlock_irqrestore space of kprobe_flush_task function 
there will be deadlock also.

> 
> With those two functions added to the blacklist (I'm not sure that is
> the right fix, I just want to get past those two functions), the
> following works correctly:
> 
> probe kernel.function("*@kernel/*") { printf("here\n"); }
> 
> Now your first probe (probing the entire kernel) still fails.  I'm
> trying to narrow it down.
> 
> --
> David Smith
> dsmith@redhat.com
> Red Hat, Inc.
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)
>