[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.02.1107301031560.4925@p34.internal.lan>
Date: Sat, 30 Jul 2011 10:32:39 -0400 (EDT)
From: Justin Piszcz <jpiszcz@...idpixels.com>
To: Stanislaw Gruszka <sgruszka@...hat.com>
cc: Larry Finger <Larry.Finger@...inger.net>,
Ivo van Doorn <IvDoorn@...il.com>,
linux-kernel@...r.kernel.org, linux-wireless@...r.kernel.org,
Alan Piszcz <ap@...arrain.com>,
"users@...x00.serialmonkey.com" <users@...x00.serialmonkey.com>
Subject: Re: [PATCH] rt2x00: rt2800: fix zeroing skb structure
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@...nel.org # 2.6.36+
>>> Signed-off-by: Stanislaw Gruszka <sgruszka@...hat.com>
>>> ---
>>> 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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists