From: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: Jim Keniston <jkenisto@linux.vnet.ibm.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Yong Zhang <yong.zhang0@gmail.com>,
paulus@samba.org, yrl.pp-manager.tt@hitachi.com,
linuxppc-dev@lists.ozlabs.org
Subject: Re: [BUG?]3.0-rc4+ftrace+kprobe: set kprobe at instruction 'stwu' lead to system crash/freeze
Date: Tue, 28 Jun 2011 16:11:28 +0530 [thread overview]
Message-ID: <20110628104128.GA4310@in.ibm.com> (raw)
In-Reply-To: <20110627100104.GA24705@in.ibm.com>
On Mon, Jun 27, 2011 at 03:31:05PM +0530, Ananth N Mavinakayanahalli wrote:
> On Sun, Jun 26, 2011 at 11:47:13PM +0900, Masami Hiramatsu wrote:
> > (2011/06/24 19:29), Steven Rostedt wrote:
> > > On Fri, 2011-06-24 at 17:21 +0800, Yong Zhang wrote:
> > >> Hi,
> > >>
> > >> When I use kprobe to do something, I found some wired thing.
> > >>
> > >> When CONFIG_FUNCTION_TRACER is disabled:
> > >> (gdb) disassemble do_fork
> > >> Dump of assembler code for function do_fork:
> > >> 0xc0037390 <+0>: mflr r0
> > >> 0xc0037394 <+4>: stwu r1,-64(r1)
> > >> 0xc0037398 <+8>: mfcr r12
> > >> 0xc003739c <+12>: stmw r27,44(r1)
> > >>
> > >> Then I:
> > >> modprobe kprobe_example func=do_fork offset=4
> > >> ls
> > >> Things works well.
> > >>
> > >> But when CONFIG_FUNCTION_TRACER is enabled:
> > >> (gdb) disassemble do_fork
> > >> Dump of assembler code for function do_fork:
> > >> 0xc0040334 <+0>: mflr r0
> > >> 0xc0040338 <+4>: stw r0,4(r1)
> > >> 0xc004033c <+8>: bl 0xc00109d4 <mcount>
> > >> 0xc0040340 <+12>: stwu r1,-80(r1)
> > >> 0xc0040344 <+16>: mflr r0
> > >> 0xc0040348 <+20>: stw r0,84(r1)
> > >> 0xc004034c <+24>: mfcr r12
> > >> Then I:
> > >> modprobe kprobe_example func=do_fork offset=12
> > >> ls
> > >> 'ls' will never retrun. system freeze.
My access to a 32bit powerpc box is very limited. Also, embedded powerpc
has had issues with gcc-4.6 while gcc-4.5 worked fine.
> > > I'm not sure if x86 had a similar issue.
> > >
> > > Masami, have any ideas to why this happened?
> >
> > No, I don't familiar with ppc implementation. I guess
> > that single-step resume code failed to emulate the
> > instruction, but it strongly depends on ppc arch.
> > Maybe IBM people may know what happened.
> >
> > Ananth, Jim, would you have any ideas?
>
> On powerpc, we emulate sstep whenever possible. Only recently support to
> emulate loads and stores got added. I don't have access to a powerpc box
> today... but will try to recreate the problem ASAP and see what could be
> happening in the presence of mcount.
I tried to recreate this problem on a 64-bit pSeries box without
success. Every one of the instructions in the stream at .do_fork are
emulated and work fine there -- no hangs/crashes with or without
function tracer.
Yong,
I am copying Kumar to see if he knows of any issues with 32-bit kprobes
(he wrote it) or with the function tracer, or with the toolchain itself.
You may want to check if, in the failure case, the instruction in
question is single-stepped or emulated (print out the value of
kprobe->ainsn.boostable in the post_handler) and see if you can find a
pattern to the failure.
Ananth
next prev parent reply other threads:[~2011-06-28 10:41 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-24 9:21 [BUG?]3.0-rc4+ftrace+kprobe: set kprobe at instruction 'stwu' lead to system crash/freeze Yong Zhang
2011-06-24 10:29 ` Steven Rostedt
2011-06-26 14:47 ` Masami Hiramatsu
2011-06-27 10:01 ` Ananth N Mavinakayanahalli
2011-06-28 10:41 ` Ananth N Mavinakayanahalli [this message]
2011-06-28 13:15 ` Steven Rostedt
2011-06-29 6:41 ` Yong Zhang
2011-06-29 6:23 ` Yong Zhang
2011-06-29 6:46 ` Ananth N Mavinakayanahalli
2011-06-30 7:08 ` Yong Zhang
2011-07-01 10:03 ` tiejun.chen
2011-07-04 2:23 ` Yong Zhang
2011-11-30 4:19 ` Benjamin Herrenschmidt
2011-11-30 11:06 ` tiejun.chen
2011-11-30 21:00 ` Benjamin Herrenschmidt
2011-12-01 10:44 ` tiejun.chen
2011-12-01 21:37 ` Benjamin Herrenschmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110628104128.GA4310@in.ibm.com \
--to=ananth@in.ibm.com \
--cc=jkenisto@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=masami.hiramatsu.pt@hitachi.com \
--cc=paulus@samba.org \
--cc=rostedt@goodmis.org \
--cc=yong.zhang0@gmail.com \
--cc=yrl.pp-manager.tt@hitachi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).