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

From: Anton Vorontsov
Date: Wed Jul 18 2012 - 03:28:18 EST

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

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}()?


Anton Vorontsov
Email: cbouatmailru@xxxxxxxxx
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at