Re: [PATCH] rt2x00: rt2800: fix zeroing skb structure

[Justin Piszcz]

On Sat, 30 Jul 2011, Justin Piszcz wrote:

> On Sat, 30 Jul 2011, Justin Piszcz wrote:
>
> > On Sat, 30 Jul 2011, Stanislaw Gruszka wrote:
> >
> > > We should clear skb->data not skb itself. Bug was introduced by:
> > > commit 0b8004aa12d13ec750d102ba4082a95f0107c649 "rt2x00: Properly
> > > reserve room for descriptors in skbs".
> > >
> > > Cc: stable@xxxxxxxxxx # 2.6.36+
> > > Signed-off-by: Stanislaw Gruszka <sgruszka@xxxxxxxxxx>
> > > ---
> > > drivers/net/wireless/rt2x00/rt2800lib.c |    3 +--
> > > 1 files changed, 1 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c 
> > > b/drivers/net/wireless/rt2x00/rt2800lib.c
> > > index 75d2c6c..f94d669 100644
> > > --- a/drivers/net/wireless/rt2x00/rt2800lib.c
> > > +++ b/drivers/net/wireless/rt2x00/rt2800lib.c
> > > @@ -703,8 +703,7 @@ void rt2800_write_beacon(struct queue_entry *entry, 
> > > struct txentry_desc *txdesc)
> > > 	/*
> > > 	 * Add space for the TXWI in front of the skb.
> > > 	 */
> > > -	skb_push(entry->skb, TXWI_DESC_SIZE);
> > > -	memset(entry->skb, 0, TXWI_DESC_SIZE);
> > > +	memset(skb_push(entry->skb, TXWI_DESC_SIZE), 0, TXWI_DESC_SIZE);
> > >
> > > 	/*
> > > 	 * Register descriptor details in skb frame descriptor.
> > > --
> > > 1.7.4
> >
> > Hi,
> >
> > Testing w/ Linux kernel 3.0:
> >
> > # patch -p1 < ../patch3
> > patching file drivers/net/wireless/rt2x00/rt2800lib.c
> > Hunk #1 succeeded at 784 (offset 81 lines).
> >
> > Compiled/installed.
> >
> > Will reboot shortly, need to run a backup first, thanks.
> >
> > Justin.
>
> Hi,
>
> Patched, its working, latency is MUCH better than before the patch!
>
> PING atomw.internal.lan (192.168.0.2) 56(84) bytes of data.
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=1 ttl=64 time=0.535 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=2 ttl=64 time=0.589 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=3 ttl=64 time=48.8 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=4 ttl=64 time=1.14 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=5 ttl=64 time=64.5 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=6 ttl=64 time=0.582 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=7 ttl=64 time=80.6 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=8 ttl=64 time=51.9 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=9 ttl=64 time=35.5 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=10 ttl=64 time=0.614 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=11 ttl=64 time=0.497 
> ms
> 64 bytes from atomw.internal.lan (192.168.0.2): icmp_req=12 ttl=64 time=41.5 
> ms
>
> $ uptime
> 10:19:18 up 5 min,  2 users,  load average: 1.32, 1.02, 0.47
>
> It hasn't crashed yet, if you don't hear from me/stating it has crashed 
> again,
> then you can assume its stable, I'll let you know if anything happens.

Hmm..

The joy was short lived :(
$ ssh: connect to host atomw port 22: No route to host

Going to see if there is a dump now.

Justin.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/