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;
- 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