[PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[Marc Kleine-Budde]

From: Helmut Schaa <helmut.schaa@googlemail.com>

ath9k_htc adds padding between the 802.11 header and the payload during
TX by moving the header. When handing the frame back to mac80211 for TX
status handling the header is not moved back into its original position.
This can result in a too small skb headroom when entering ath9k_htc
again (due to a soft retransmission for example) causing an
skb_under_panic oops.

Fix this by moving the 802.11 header back into its original position
before returning the frame to mac80211 as other drivers like rt2x00
or ath5k do.

Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
---
Hello Helmut,

I've change the patch a bit, I've used ieee80211_get_hdrlen_from_skb() instead
of open coding it.

Tested in ARMv5 with USB device
  "ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]"
for four weeks. Without that patch the kernel oopes after about one week.

I think this is a candidate for stable, can you add stable to Cc?

regards,
Marc

changes since v1:
- use ieee80211_get_hdrlen_from_skb() instead of open coding it

 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index e602c95..c028df7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -448,6 +448,7 @@ static void ath9k_htc_tx_process(struct ath9k_htc_priv *priv,
 	struct ieee80211_conf *cur_conf = &priv->hw->conf;
 	bool txok;
 	int slot;
+	int hdrlen, padsize;
 
 	slot = strip_drv_header(priv, skb);
 	if (slot < 0) {
@@ -504,6 +505,15 @@ send_mac80211:
 
 	ath9k_htc_tx_clear_slot(priv, slot);
 
+	/* Remove padding before handing frame back to mac80211 */
+	hdrlen = ieee80211_get_hdrlen_from_skb(skb);
+
+	padsize = hdrlen & 3;
+	if (padsize && skb->len > hdrlen + padsize) {
+		memmove(skb->data + padsize, skb->data, hdrlen);
+		skb_pull(skb, padsize);
+	}
+
 	/* Send status to mac80211 */
 	ieee80211_tx_status(priv->hw, skb);
 }
-- 
1.8.3.1

[ath9k-devel] [PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[Marc Kleine-Budde]

From: Helmut Schaa <helmut.schaa@googlemail.com>

ath9k_htc adds padding between the 802.11 header and the payload during
TX by moving the header. When handing the frame back to mac80211 for TX
status handling the header is not moved back into its original position.
This can result in a too small skb headroom when entering ath9k_htc
again (due to a soft retransmission for example) causing an
skb_under_panic oops.

Fix this by moving the 802.11 header back into its original position
before returning the frame to mac80211 as other drivers like rt2x00
or ath5k do.

Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
---
Hello Helmut,

I've change the patch a bit, I've used ieee80211_get_hdrlen_from_skb() instead
of open coding it.

Tested in ARMv5 with USB device
  "ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]"
for four weeks. Without that patch the kernel oopes after about one week.

I think this is a candidate for stable, can you add stable to Cc?

regards,
Marc

changes since v1:
- use ieee80211_get_hdrlen_from_skb() instead of open coding it

 drivers/net/wireless/ath/ath9k/htc_drv_txrx.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
index e602c95..c028df7 100644
--- a/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
+++ b/drivers/net/wireless/ath/ath9k/htc_drv_txrx.c
@@ -448,6 +448,7 @@ static void ath9k_htc_tx_process(struct ath9k_htc_priv *priv,
 	struct ieee80211_conf *cur_conf = &priv->hw->conf;
 	bool txok;
 	int slot;
+	int hdrlen, padsize;
 
 	slot = strip_drv_header(priv, skb);
 	if (slot < 0) {
@@ -504,6 +505,15 @@ send_mac80211:
 
 	ath9k_htc_tx_clear_slot(priv, slot);
 
+	/* Remove padding before handing frame back to mac80211 */
+	hdrlen = ieee80211_get_hdrlen_from_skb(skb);
+
+	padsize = hdrlen & 3;
+	if (padsize && skb->len > hdrlen + padsize) {
+		memmove(skb->data + padsize, skb->data, hdrlen);
+		skb_pull(skb, padsize);
+	}
+
 	/* Send status to mac80211 */
 	ieee80211_tx_status(priv->hw, skb);
 }
-- 
1.8.3.1

Re: [PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[Marc Kleine-Budde]

[-- Attachment #1: Type: text/plain, Size: 1325 bytes --]

On 08/16/2013 09:39 PM, Marc Kleine-Budde wrote:
> From: Helmut Schaa <helmut.schaa@googlemail.com>
> 
> ath9k_htc adds padding between the 802.11 header and the payload during
> TX by moving the header. When handing the frame back to mac80211 for TX
> status handling the header is not moved back into its original position.
> This can result in a too small skb headroom when entering ath9k_htc
> again (due to a soft retransmission for example) causing an
> skb_under_panic oops.
> 
> Fix this by moving the 802.11 header back into its original position
> before returning the frame to mac80211 as other drivers like rt2x00
> or ath5k do.
> 
> Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
> Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
> ---
> Hello Helmut,
> 
> I've change the patch a bit, I've used ieee80211_get_hdrlen_from_skb() instead
> of open coding it.
> 
> Tested in ARMv5 with USB device
>   "ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]"
> for four weeks. Without that patch the kernel oopes after about one week.
> 
> I think this is a candidate for stable, can you add stable to Cc?

ping

Marc


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 897 bytes --]

[ath9k-devel] [PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[Marc Kleine-Budde]

On 08/16/2013 09:39 PM, Marc Kleine-Budde wrote:
> From: Helmut Schaa <helmut.schaa@googlemail.com>
> 
> ath9k_htc adds padding between the 802.11 header and the payload during
> TX by moving the header. When handing the frame back to mac80211 for TX
> status handling the header is not moved back into its original position.
> This can result in a too small skb headroom when entering ath9k_htc
> again (due to a soft retransmission for example) causing an
> skb_under_panic oops.
> 
> Fix this by moving the 802.11 header back into its original position
> before returning the frame to mac80211 as other drivers like rt2x00
> or ath5k do.
> 
> Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
> Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
> Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
> ---
> Hello Helmut,
> 
> I've change the patch a bit, I've used ieee80211_get_hdrlen_from_skb() instead
> of open coding it.
> 
> Tested in ARMv5 with USB device
>   "ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]"
> for four weeks. Without that patch the kernel oopes after about one week.
> 
> I think this is a candidate for stable, can you add stable to Cc?

ping

Marc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
Url : http://lists.ath9k.org/pipermail/ath9k-devel/attachments/20130820/169cba71/attachment.pgp 

Re: [PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[Helmut Schaa]

Hi John, Hi Marc,

On Tue, Aug 20, 2013 at 11:01 AM, Marc Kleine-Budde <mkl@blackshift.org> wrote:
> On 08/16/2013 09:39 PM, Marc Kleine-Budde wrote:
>> From: Helmut Schaa <helmut.schaa@googlemail.com>
>>
>> ath9k_htc adds padding between the 802.11 header and the payload during
>> TX by moving the header. When handing the frame back to mac80211 for TX
>> status handling the header is not moved back into its original position.
>> This can result in a too small skb headroom when entering ath9k_htc
>> again (due to a soft retransmission for example) causing an
>> skb_under_panic oops.
>>
>> Fix this by moving the 802.11 header back into its original position
>> before returning the frame to mac80211 as other drivers like rt2x00
>> or ath5k do.
>>
>> Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
>> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>> Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
>> Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
>> ---
>> Hello Helmut,
>>
>> I've change the patch a bit, I've used ieee80211_get_hdrlen_from_skb() instead
>> of open coding it.
>>
>> Tested in ARMv5 with USB device
>>   "ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]"
>> for four weeks. Without that patch the kernel oopes after about one week.
>>
>> I think this is a candidate for stable, can you add stable to Cc?
>
> ping

Sorry, completely forgot about this patch. You're right, this is
indeed a stable candidate.

John, could you please add  "Cc: stable@vger.kernel.org" when applying
this to your tree?

Thanks,
Helmut

[ath9k-devel] [PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[Helmut Schaa]

Hi John, Hi Marc,

On Tue, Aug 20, 2013 at 11:01 AM, Marc Kleine-Budde <mkl@blackshift.org> wrote:
> On 08/16/2013 09:39 PM, Marc Kleine-Budde wrote:
>> From: Helmut Schaa <helmut.schaa@googlemail.com>
>>
>> ath9k_htc adds padding between the 802.11 header and the payload during
>> TX by moving the header. When handing the frame back to mac80211 for TX
>> status handling the header is not moved back into its original position.
>> This can result in a too small skb headroom when entering ath9k_htc
>> again (due to a soft retransmission for example) causing an
>> skb_under_panic oops.
>>
>> Fix this by moving the 802.11 header back into its original position
>> before returning the frame to mac80211 as other drivers like rt2x00
>> or ath5k do.
>>
>> Reported-by: Marc Kleine-Budde <mkl@blackshift.org>
>> Signed-off-by: Helmut Schaa <helmut.schaa@googlemail.com>
>> Tested-by: Marc Kleine-Budde <mkl@blackshift.org>
>> Signed-off-by: Marc Kleine-Budde <mkl@blackshift.org>
>> ---
>> Hello Helmut,
>>
>> I've change the patch a bit, I've used ieee80211_get_hdrlen_from_skb() instead
>> of open coding it.
>>
>> Tested in ARMv5 with USB device
>>   "ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]"
>> for four weeks. Without that patch the kernel oopes after about one week.
>>
>> I think this is a candidate for stable, can you add stable to Cc?
>
> ping

Sorry, completely forgot about this patch. You're right, this is
indeed a stable candidate.

John, could you please add  "Cc: stable at vger.kernel.org" when applying
this to your tree?

Thanks,
Helmut

Re: [PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[Helmut Schaa]

On Fri, Aug 16, 2013 at 9:39 PM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> Tested in ARMv5 with USB device
>   "ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]"
> for four weeks. Without that patch the kernel oopes after about one week.

Thanks for testing by the way!
Helmut

[ath9k-devel] [PATCH v2] ath9k_htc: Restore skb headroom when returning skb to mac80211

[Helmut Schaa]

On Fri, Aug 16, 2013 at 9:39 PM, Marc Kleine-Budde <mkl@pengutronix.de> wrote:
> Tested in ARMv5 with USB device
>   "ID 0cf3:7015 Atheros Communications, Inc. TP-Link TL-WN821N v3 802.11n [Atheros AR7010+AR9287]"
> for four weeks. Without that patch the kernel oopes after about one week.

Thanks for testing by the way!
Helmut