This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
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
Red Hat, Inc.
256.217.0141 (direct)
256.837.0057 (fax)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]