Messages in this thread | ![/](/images/icornerl.gif) | | Subject | Re: [PATCH] Fix tracing infrastructure to support multiple includes when defining CREATE_TRACE_POINTS | From | Steven Rostedt <> | Date | Tue, 15 Dec 2009 23:13:49 -0500 |
| |
On Tue, 2009-12-15 at 11:08 -0500, Neil Horman wrote:
Hi Neil,
I was playing with this, and I got really nasty errors in the trace parsing tools. Then I noticed why:
> -DECLARE_TRACE(napi_poll, > +TRACE_EVENT(napi_poll, > + > TP_PROTO(struct napi_struct *napi), > - TP_ARGS(napi)); > + > + TP_ARGS(napi), > + > + TP_STRUCT__entry( > + __field( struct napi_struct *, napi) > + ), > + > + TP_fast_assign( > + __entry->napi = napi; > + ), > + > + TP_printk("napi poll on napi struct %p for device %s", > + __entry->napi, __entry->napi->dev->name)
You can't trust this! That "__entry" happens to reside on the ring buffer. If for some reason the device goes away, this blows up when you read the trace.
If you need to save the name of the device, then store it in the ring buffer. You can do it with a dynamic array:
TP_STRUCT__entry( __field( struct napi_struct *, napi) __string( dev_name, napi->dev->name) ),
TP_fast_assign( __entry->napi = napi; __assign_str(dev_name, napi->dev->name); ),
TP_printk("napi poll on napi struct %p for device %s", __entry->napi, __get_string(dev_name))
-- Steve
> +); > > #endif
| ![\](/images/icornerr.gif) |