From: Michael Ellerman <michael@ellerman.id.au>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linuxppc-dev@ozlabs.org, Anton Blanchard <anton@samba.org>
Subject: Re: [PATCH] powerpc: Fix stack overflow crash in resume_kernel when ftracing
Date: Fri, 14 Jun 2013 00:31:02 +1000 [thread overview]
Message-ID: <1371133862.23094.15.camel@concordia> (raw)
In-Reply-To: <1371127506.9844.275.camel@gandalf.local.home>
On Thu, 2013-06-13 at 08:45 -0400, Steven Rostedt wrote:
> On Thu, 2013-06-13 at 21:04 +1000, Michael Ellerman wrote:
>
> > Although that should be sufficient to fix the bug, we also mark the
> > runlatch routines as notrace. They are called very early in the
> > exception entry and we are asking for trouble tracing them. They are
> > also fairly uninteresting and tracing them just adds unnecessary
> > overhead.
>
> Note, I usually lean towards tracing everything that can be traced, and
> only adding notrace to things that will actually cause a crash. If you
> don't like them to be traced, you can always do:
Yeah fair enough. In this case I think we don't want to trace it.
Although it doesn't cause a crash right now (at least after part 1 of
this patch), it's being called at a time when things are fragile, and
it's possible we could get bitten again some other way if the
surrounding code changes.
> echo '*__ppc64_runlatch_*'
> > /sys/kernel/debug/tracing/set_ftrace_notrace
>
> and that will keep them from being traced. You can also add it to the
> kernel command line with: ftrace_notrace=*__ppc64_runlatch_* which will
> also disable them on boot up.
>
> Also trace-cmd has:
>
> trace-cmd record -p function_graph -n '*__ppc64_runlatch_*'
>
> that will do the same thing.
>
> Hmm, I should add a way to disable things that are usually considered
> noise. Perhaps add something like:
>
>
> FTRACE_DEFAULT_OFF(__ppc64_runlatch_on);
>
> That adds the function to a different section that places it into
> another file that keeps it from being traced, but can be enabled when
> you want it to.
Yeah that would be cool.
Personally I'm just using shell scripts that poke the files in sysfs,
and I'm often running on different boxes, so the more that just works
without extra config by me the better.
cheers
next prev parent reply other threads:[~2013-06-13 14:31 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-13 11:04 [PATCH] powerpc: Fix stack overflow crash in resume_kernel when ftracing Michael Ellerman
2013-06-13 12:45 ` Steven Rostedt
2013-06-13 14:31 ` Michael Ellerman [this message]
2013-06-13 14:46 ` Steven Rostedt
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=1371133862.23094.15.camel@concordia \
--to=michael@ellerman.id.au \
--cc=anton@samba.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=rostedt@goodmis.org \
/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).