This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: 3 bugs found.
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)