Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 691ba234 authored by Johannes Berg's avatar Johannes Berg Committed by David S. Miller
Browse files

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: default avatarJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
parent 4bdb0fba

net/mac80211/rx.c

+33 −13
Original line number Diff line number Diff line
@@ -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++;