From: Frederic Weisbecker <fweisbec@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "Tim Bird" <tim.bird@am.sony.com>,
"linux kernel" <linux-kernel@vger.kernel.org>,
linux-arm-kernel <linux-arm-kernel@lists.arm.linux.org.uk>,
"Ingo Molnar" <mingo@elte.hu>,
"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
"Russell King" <rmk+kernel@arm.linux.org.uk>
Subject: Re: [PATCH 1/2] ftrace: add notrace to ARM sched_clock routines
Date: Sat, 2 May 2009 01:54:15 +0200 [thread overview]
Message-ID: <20090501235414.GG6404@nowhere> (raw)
In-Reply-To: <alpine.DEB.2.00.0905011942390.20374@gandalf.stny.rr.com>
On Fri, May 01, 2009 at 07:43:50PM -0400, Steven Rostedt wrote:
>
> On Sat, 2 May 2009, Frederic Weisbecker wrote:
> > > }
> > > @@ -203,7 +203,7 @@ static struct clocksource clocksource_32
> > > * Returns current time from boot in nsecs. It's OK for this to wrap
> > > * around for now, as it's just a relative time stamp.
> > > */
> > > -unsigned long long sched_clock(void)
> > > +unsigned long long notrace sched_clock(void)
> > > {
> > > unsigned long long ret;
> >
> >
> > I've looked into all of these functions and they don't seem to call
> > anything that could be traced. I could have missed something though
> > but it looks good.
>
> I think the issue is that the tracing clock will call these functions, and
> we will waste time recursing into them.
Indeed, but I wanted to ensure that none of these sched_clock() were calling
any traceable function, or it would recurse inside the function graph
low level helpers which are not protected. Hence an endless stack overrun which
ends up on an immediate reboot :)
But it looks good.
> >
> > Acked-by: Frederic Weisbecker <fweisbec@gmail.com>
>
> Heck I'll add mine too ;-)
>
> Acked-by: Steven Rostedt <rostedt@goodmis.org>
>
> -- Steve
>
prev parent reply other threads:[~2009-05-01 23:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-01 22:30 [PATCH 1/2] ftrace: add notrace to ARM sched_clock routines Tim Bird
2009-05-01 23:03 ` Steven Rostedt
2009-05-01 23:37 ` Frederic Weisbecker
2009-05-01 23:43 ` Steven Rostedt
2009-05-01 23:54 ` Frederic Weisbecker [this message]
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=20090501235414.GG6404@nowhere \
--to=fweisbec@gmail.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rmk+kernel@arm.linux.org.uk \
--cc=rostedt@goodmis.org \
--cc=tim.bird@am.sony.com \
--cc=u.kleine-koenig@pengutronix.de \
/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