From 691ba2346d5b88cec62fe8db0bf336a58a07b926 Mon Sep 17 00:00:00 2001 From: Johannes Berg Date: Fri, 11 Jan 2008 02:02:51 +0100 Subject: [PATCH] mac80211: fix alignment warning When I introduced the alignment warning I forgot the A-MSDU case which has a different requirement because each frame contains 14-byte 802.3 headers in front of the IP payload. This patch moves the alignment warning to a place where we know whether we're dealing with an A-MSDU frame and adjusts it accordingly. Signed-off-by: Johannes Berg Signed-off-by: John W. Linville Signed-off-by: David S. Miller --- net/mac80211/rx.c | 46 +++++++++++++++++++++++++++++++++------------- 1 file changed, 33 insertions(+), 13 deletions(-) diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c index 89e1e3070e..1ccd32933e 100644 --- a/net/mac80211/rx.c +++ b/net/mac80211/rx.c @@ -340,9 +340,42 @@ static u32 ieee80211_rx_load_stats(struct ieee80211_local *local, return load; } +static ieee80211_txrx_result +ieee80211_rx_h_verify_ip_alignment(struct ieee80211_txrx_data *rx) +{ + int hdrlen; + + /* + * Drivers are required to align the payload data in a way that + * guarantees that the contained IP header is aligned to a four- + * byte boundary. In the case of regular frames, this simply means + * aligning the payload to a four-byte boundary (because either + * the IP header is directly contained, or IV/RFC1042 headers that + * have a length divisible by four are in front of it. + * + * With A-MSDU frames, however, the payload data address must + * yield two modulo four because there are 14-byte 802.3 headers + * within the A-MSDU frames that push the IP header further back + * to a multiple of four again. Thankfully, the specs were sane + * enough this time around to require padding each A-MSDU subframe + * to a length that is a multiple of four. + * + * Padding like atheros hardware adds which is inbetween the 802.11 + * header and the payload is not supported, the driver is required + * to move the 802.11 header further back in that case. + */ + hdrlen = ieee80211_get_hdrlen(rx->fc); + if (rx->flags & IEEE80211_TXRXD_RX_AMSDU) + hdrlen += ETH_HLEN; + WARN_ON_ONCE(((unsigned long)(rx->skb->data + hdrlen)) & 3); + + return TXRX_CONTINUE; +} + ieee80211_rx_handler ieee80211_rx_pre_handlers[] = { ieee80211_rx_h_parse_qos, + ieee80211_rx_h_verify_ip_alignment, NULL }; @@ -1679,7 +1712,6 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw, struct ieee80211_sub_if_data *prev = NULL; struct sk_buff *skb_new; u8 *bssid; - int hdrlen; hdr = (struct ieee80211_hdr *) skb->data; memset(&rx, 0, sizeof(rx)); @@ -1691,18 +1723,6 @@ static void __ieee80211_rx_handle_packet(struct ieee80211_hw *hw, rx.fc = le16_to_cpu(hdr->frame_control); type = rx.fc & IEEE80211_FCTL_FTYPE; - /* - * Drivers are required to align the payload data to a four-byte - * boundary, so the last two bits of the address where it starts - * may not be set. The header is required to be directly before - * the payload data, padding like atheros hardware adds which is - * inbetween the 802.11 header and the payload is not supported, - * the driver is required to move the 802.11 header further back - * in that case. - */ - hdrlen = ieee80211_get_hdrlen(rx.fc); - WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3); - if (type == IEEE80211_FTYPE_DATA || type == IEEE80211_FTYPE_MGMT) local->dot11ReceivedFragmentCount++; -- 2.39.5