Re: [PATCH] pstore/ftrace: Convert to its own enable/disable debugfs knob

[Steven Rostedt <rostedt@goodmis.org>]

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