Re: [RFC PATCH 1/2] PM/runtime: introduce trace points for tracing rpm_* functions

[Steven Rostedt <rostedt@goodmis.org>]

On Tue, 2011-09-27 at 09:45 +0800, Ming Lei wrote:

> > Not to mention, this will never work with tools such as perf or
> > trace-cmd, that will just get a pointer address and will try to read a
> > string that points inside the kernel.
> 
> Ok, sounds like dev_name does not work for the case, I will update
> the patch, but I am wondering why no such problem for dev_dbg?
> printk still may buffer these for sometime in some cases.
> 


printk will push out to the console immediately. Whatever is in the
buffer has already been processed into a string. With tracing, we save
the data as defined by TP_fast_assign() and is printed later when the
user asks in TP_printk().

> >
> > This will only work with reading the trace data
> > from /debug/tracing/trace, but not from any tools. The pS *will* work
> > with the tools as the tools load the kallsyms data, and is smart enough
> > to figure this pointer out.
> 
> __func__ points to a const string, which will be stored in kernel global
> read-only section, I think perf can read correct string from the pointer
> anytime, don't I?

That would be very dangerous to let a userspace app have any access to
reading the kernel memory. Not to mention, this data may be sent out
over the network to another machine, which must be able to read this
data too.

-- Steve