Linux wireless networking development ()

Re: mac80211 truesize bugs

On Thursday 01 May 2008 11:08:06 Johannes Berg wrote:
> 
> > Hm, unrelated to this...
> > But I am wondering what happens if the driver adds a device header to the skb.
> > Is that header then also passed up netif_rx()?
> > This doesn't happen for b43, as we use the DMA fragmentation to transmit the header,
> > but it might happen for zd1211rw and others.
> 
> Hmm. I thought we said that it was supposed to be removed again by the
> hardware before TX status reporting. That's what most drivers seem to do
> anyway.

Ok. I was not aware of that. Is that documented somewhere? I guess we can't WARN_ON()?

> > Seems the skb->destructor messes it up.
> 
> Actually, it seems to be outside of mac80211, I put in a WARN_ON() and
> got this:

Yeah looks like the destructor messes with the data/sizes and disagrees
with the way mac80211 handles stuff, in some way.

> Badness at include/linux/skbuff.h:392
> NIP: c026ea14 LR: c0273d54 CTR: c026e9e4
> REGS: edfc7c00 TRAP: 0700   Not tainted  (2.6.25-wl-06841-g6b3d5c6-dirty)
> MSR: 00029032 <EE,ME,IR,DR>  CR: 82022444  XER: 00000000
> TASK = edf50e20[3453] 'tcpdump' THREAD: edfc6000
> GPR00: 00000001 edfc7cb0 edf50e20 edfd7700 edfd7700 00000002 edfc7e75 03230306 
> GPR08: 02000100 00000168 4dff0200 00000150 22022442 100a6290 100783f8 10078e18 
> GPR16: 10078e14 10078e10 100a0000 00000000 00000000 bfe2c9d2 1004d320 bfe2c4b0

(Continue reading)

headers

Johannes Berg | 1 May 11:34

Re: mac80211 truesize bugs

On Thu, 2008-05-01 at 11:32 +0200, Michael Buesch wrote:
> On Thursday 01 May 2008 11:08:06 Johannes Berg wrote:
> > 
> > > Hm, unrelated to this...
> > > But I am wondering what happens if the driver adds a device header to the skb.
> > > Is that header then also passed up netif_rx()?
> > > This doesn't happen for b43, as we use the DMA fragmentation to transmit the header,
> > > but it might happen for zd1211rw and others.
> > 
> > Hmm. I thought we said that it was supposed to be removed again by the
> > hardware before TX status reporting. That's what most drivers seem to do
> > anyway.
> 
> Ok. I was not aware of that. Is that documented somewhere? I guess we can't WARN_ON()?

Not sure. We could try to analyse the packet header and see if it's
802.11, or put a length into skb->cb (after my rework to put things into
skb->cb we have a single byte free so we could check skb->len % 256)

johannes