This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: kernel panic when kretprobe all system calls
- From: Guang Lei Li <liguangl at cn dot ibm dot com>
- To: systemtap at sources dot redhat dot com
- Cc: fche at elastic dot org, hien at us dot ibm dot com
- Date: Tue, 8 Nov 2005 10:30:51 +0800
- Subject: Re: kernel panic when kretprobe all system calls
systemtap-owner@sources.redhat.com wrote on 2005-09-26 23:55:08:
> Frank Ch. Eigler wrote:
>
> >Hi -
> >
> >>[... kretprobes on syscalls ...]
> >
> >This has been seen before, and is being tracked as bug #1345 in
> >bugzilla. It has apparently been reproduced by the kretprobes
> >developers and is being debugged. More RAM seems to trigger the
> >bug less often.
> >
> >- FChE
> >
> It helps if we don't insert return probes in sys_calls such as
> sys_execve, sys_exit, sys_groupexit. Frank, can we tempory put an
> retprobe embargo policy on those system calls?
>
> Hien.
>
Hi, how is the bug #1345 going now? I ran the latest systemTap to probe
all returns of syscalls on my x86, and still got kernel panic. Although
I didn't meet the same problem on my Power5 system, I think it is due to
the large RAM of it(15G)
I looked into the comments in the bugzilla, and found Hien has worked
out a fix for i386. But he abandoned his idea because of not portable.
So at present, will I avoid this problem only by not probing the return
of those syscalls in the blacklist? Is there a better solution now?
Thanks.