On Tue, Jul 17, 2012 at 03:38:18PM -0400, Steven Rostedt wrote: [...] > > +void notrace pstore_ftrace_call(unsigned long ip, unsigned long parent_ip) > > BTW, you can make the entire file 'notrace' without adding annotations > by including in the Makefile: > > CFLAGS_REMOVE_ftrace.o = -pg Actually it was in the first version in the patch, but then I changed it 'notrace' for just this func. This is for the case if the file would contain some more code which we actually may trace. Doing things fine- grained seemed to be better than making the whole file as notrace. Plus it is one line less. :-) But I have no preference, so I can change it. > > +{ > > + struct pstore_ftrace_record rec = {}; > > + > > + if (unlikely(oops_in_progress)) > > + return; > > + > > + 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, can any of the called functions go into module code that can be > removed? If so, then this is not safe at all. Normal function tracing > can not be synced in a preemptible kernel. Um. Yes, psinfo->write_buf() might be in the module. Nice catch. > Also, I'm starting to wonder if this should be in its own utility > (separate debugfs?) than hooking directly into ftrace. Then you don't > need to modify ftrace at all and you can do the following: > > static struct ftrace_ops trace_ops { > .func = pstore_ftrace_call; > }; > > then in your write to debugfs file: > > register_ftrace_function(&trace_ops); > > To turn off tracing: > > unregister_ftrace_function(&trace_ops); > > Note, it's safe to use if the trace_ops (or anything the callback calls) > is a module. That's because it detects the trace_ops is not kernel core > code and will place a wrapper around it that allows the function tracing > to by synced with module unload. You still need to unregister the > trace_ops before unloading the module, or you can have a crash that way. Hehe. Like this? http://lkml.org/lkml/2012/5/26/80 :-D So, do you want something like this, but combinded: we don't register another tracer, but register our own ftrace_ops? This sounds doable. Thanks! -- Anton Vorontsov Email: cbouatmailru@xxxxxxxxx _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/devel