[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1342617199.11900.5.camel@gandalf.stny.rr.com>
Date: Wed, 18 Jul 2012 09:13:19 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Anton Vorontsov <anton.vorontsov@...aro.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Kees Cook <keescook@...omium.org>,
Colin Cross <ccross@...roid.com>,
Tony Luck <tony.luck@...el.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Ingo Molnar <mingo@...hat.com>, Arnd Bergmann <arnd@...db.de>,
John Stultz <john.stultz@...aro.org>,
Shuah Khan <shuahkhan@...il.com>, arve@...roid.com,
Rebecca Schultz Zavin <rebecca@...roid.com>,
Jesper Juhl <jj@...osbits.net>,
Randy Dunlap <rdunlap@...otime.net>,
Stephen Boyd <sboyd@...eaurora.org>,
Thomas Meyer <thomas@...3r.de>,
Andrew Morton <akpm@...ux-foundation.org>,
Marco Stornelli <marco.stornelli@...il.com>,
WANG Cong <xiyou.wangcong@...il.com>,
linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
linaro-kernel@...ts.linaro.org, patches@...aro.org,
kernel-team@...roid.com
Subject: Re: [PATCH] pstore/ftrace: Convert to its own enable/disable
debugfs knob
On Wed, 2012-07-18 at 00:26 -0700, Anton Vorontsov wrote:
> On Tue, Jul 17, 2012 at 08:47:22PM -0700, Anton Vorontsov wrote:
> [...]
> > -void notrace pstore_ftrace_call(unsigned long ip, unsigned long parent_ip)
> > +static void notrace pstore_ftrace_call(unsigned long ip,
> > + unsigned long parent_ip)
> > {
> > + unsigned long flags;
> > struct pstore_ftrace_record rec = {};
> >
> > + if (unlikely(!ftrace_enabled))
> > + return;
> > if (unlikely(oops_in_progress))
> > return;
> >
> > + local_irq_save(flags);
> > +
> > rec.ip = ip;
> > rec.parent_ip = parent_ip;
> > pstore_ftrace_encode_cpu(&rec, raw_smp_processor_id());
> > psinfo->write_buf(PSTORE_TYPE_FTRACE, 0, NULL, 0, (void *)&rec,
> > sizeof(rec), psinfo);
>
> Btw, here we might be running w/o recurse protection, and that helped
> to find a bug in the persistent ram module.
>
> The bug was quite subtle: it only happened if pstore tracing was
> enabled before any other tracers. And it magically disappeared
> otherwise.
>
> This is because ftrace_ops_list_func() does its own recurse protection,
> but ftrace_ops_list_func() is only used when there are more than
> one 'struct ops' registered, otherwise ->func is called directly.
>
> Of course, if I specify FL_GLOBAL/FL_CONTROL flag for the tracer,
> then it will not try to call the func directly. But then there is
> a question: do we really want to set these flags if we yet don't
> want removable modules?
>
> Or, setting at least FL_CONTROL would be a good idea anyway, since
> it will then react to ftrace_function_local_{enable,disable}()?
I have a patch to fix this already. It's part of my kprobe/ftrace work.
The patch has been published here:
https://lkml.org/lkml/2012/7/11/476
I'm hoping to get this ready for 3.6. Thus, don't worry about adding
recursion protection. ftrace should do that for you.
Thanks!
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists