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: Jim Keniston <jkenisto at us dot ibm dot com>
- To: Guang Lei Li <liguangl at cn dot ibm dot com>
- Cc: SystemTAP <systemtap at sources dot redhat dot com>, fche at elastic dot org, Hien Nguyen <hien at us dot ibm dot com>
- Date: 09 Nov 2005 16:37:00 -0800
- Subject: Re: kernel panic when kretprobe all system calls
- Organization:
- References: <OF868AE59B.FC844E45-ON482570B3.000DA5B1-482570B3.000DCF48@cn.ibm.com>
On Mon, 2005-11-07 at 18:30, Guang Lei Li wrote:
> 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.
Hien and I have discussed an architecture-independent fix to kprobes
that would allow you to set return probes on "problem" functions such as
sys_execve without encountering the problems described in #1345. I've
updated the bugzilla entry.
Jim