[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.0908311503170.24907@gandalf.stny.rr.com>
Date: Mon, 31 Aug 2009 15:05:44 -0400 (EDT)
From: Steven Rostedt <rostedt@...dmis.org>
To: Neil Horman <nhorman@...driver.com>
cc: netdev@...r.kernel.org, davem@...emloft.net, mingo@...e.hu
Subject: Re: [PATCH] skb: Augment skb_copy_datagram_iovec TRACE_EVENT to dump
more info
On Fri, 28 Aug 2009, Neil Horman wrote:
> > >
> > > /*
> > > * Tracepoint for free an sk_buff:
> > > @@ -42,16 +43,35 @@ TRACE_EVENT(skb_copy_datagram_iovec,
> > > TP_ARGS(skb, len),
> > >
> > > TP_STRUCT__entry(
> > > - __field( const void *, skbaddr )
> > > + __field( const struct sk_buff *, skb )
> > > __field( int, len )
> > > + __field( int, anid )
> > > + __field( int, cnid )
> > > + __field( int, rx_queue )
> > > + __dynamic_array(char, name, IFNAMSIZ )
> >
> > For string fields we have a __string macro:
> >
> > __string( char, name )
> >
> Yeah, I was going to use that, but I ran into an issue, in that the __string
> macro expects, as its second of two arguments, a pointer to a string with witch
> to determine the dynamic arrays size. The problem is that, if I'm to provide
> that, I need to point it to skb->dev->name, and there is no guarantee that
> skb->dev isn't NULL, at which point I think the use of string breaks down. Note
> below that I obtain the dev pointer by other means and check its validity prior
> to assigning it. If theres a better way to do this, please let me know.
Ah, OK I see the issue. The problem is the code that figures out the
offset. It will always be calculated, and that would cause the skb->dev be
evaluated and if NULL will cause an OOPS.
Yeah, keep the dynamic_array here then.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists