linux-kernel - linux-next: manual merge of the net-next tree with the wireless tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-Id: <20140226142105.6e7154303b423b0eef78518d@canb.auug.org.au>
Date:	Wed, 26 Feb 2014 14:21:05 +1100
From:	Stephen Rothwell <sfr@...b.auug.org.au>
To:	David Miller <davem@...emloft.net>, <netdev@...r.kernel.org>,
	"John W. Linville" <linville@...driver.com>
Cc:	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Felix Fietkau <nbd@...nwrt.org>,
	Oleksij Rempel <linux@...pel-privat.de>
Subject: linux-next: manual merge of the net-next tree with the wireless
 tree

Hi all,

Today's linux-next merge of the net-next tree got a conflict in
drivers/net/wireless/ath/ath9k/recv.c between commit b7b146c9c9a0
("ath9k: fix invalid descriptor discarding") from the wireless tree and
commits 1274603646a8 ("ath9k: move ath9k_process_rate to common.c") and
6438696efa81 ("ath9k: move ath9k_rx_accept to common.c") from the
net-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwell                    sfr@...b.auug.org.au

diff --cc drivers/net/wireless/ath/ath9k/recv.c
index 82e340d3ec60,076dae1e5ab7..000000000000
--- a/drivers/net/wireless/ath/ath9k/recv.c
+++ b/drivers/net/wireless/ath/ath9k/recv.c
@@@ -1055,8 -853,10 +857,8 @@@ static int ath9k_rx_skb_preprocess(stru
  	 * everything but the rate is checked here, the rate check is done
  	 * separately to avoid doing two lookups for a rate for each frame.
  	 */
- 	if (!ath9k_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error))
 -	if (!ath9k_cmn_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error, sc->rx.rxfilter)) {
 -		ret = -EINVAL;
 -		goto exit;
 -	}
++	if (!ath9k_cmn_rx_accept(common, hdr, rx_status, rx_stats, decrypt_error, sc->rx.rxfilter))
 +		return -EINVAL;
  
  	if (ath_is_mybeacon(common, hdr)) {
  		RX_STAT_INC(rx_beacons);
@@@ -1066,13 -866,24 +868,21 @@@
  	/*
  	 * This shouldn't happen, but have a safety check anyway.
  	 */
 -	if (WARN_ON(!ah->curchan)) {
 -		ret = -EINVAL;
 -		goto exit;
 -	}
 +	if (WARN_ON(!ah->curchan))
 +		return -EINVAL;
  
- 	if (ath9k_process_rate(common, hw, rx_stats, rx_status))
+ 	if (ath9k_cmn_process_rate(common, hw, rx_stats, rx_status)) {
+ 		/*
+ 		 * No valid hardware bitrate found -- we should not get here
+ 		 * because hardware has already validated this frame as OK.
+ 		 */
+ 		ath_dbg(common, ANY, "unsupported hw bitrate detected 0x%02x using 1 Mbit\n",
+ 			rx_stats->rs_rate);
+ 		RX_STAT_INC(rx_rate_err);
 -		ret =-EINVAL;
 -		goto exit;
 +		return -EINVAL;
+ 	}
  
- 	ath9k_process_rssi(common, hw, rx_stats, rx_status);
+ 	ath9k_cmn_process_rssi(common, hw, rx_stats, rx_status);
  
  	rx_status->band = ah->curchan->chan->band;
  	rx_status->freq = ah->curchan->chan->center_freq;
@@@ -1085,64 -896,11 +895,13 @@@
  		sc->rx.num_pkts++;
  #endif
  
 -exit:
 -	sc->rx.discard_next = false;
 -	return ret;
 +	return 0;
 +
 +corrupt:
 +	sc->rx.discard_next = rx_stats->rs_more;
 +	return -EINVAL;
  }
  
- static void ath9k_rx_skb_postprocess(struct ath_common *common,
- 				     struct sk_buff *skb,
- 				     struct ath_rx_status *rx_stats,
- 				     struct ieee80211_rx_status *rxs,
- 				     bool decrypt_error)
- {
- 	struct ath_hw *ah = common->ah;
- 	struct ieee80211_hdr *hdr;
- 	int hdrlen, padpos, padsize;
- 	u8 keyix;
- 	__le16 fc;
- 
- 	/* see if any padding is done by the hw and remove it */
- 	hdr = (struct ieee80211_hdr *) skb->data;
- 	hdrlen = ieee80211_get_hdrlen_from_skb(skb);
- 	fc = hdr->frame_control;
- 	padpos = ieee80211_hdrlen(fc);
- 
- 	/* The MAC header is padded to have 32-bit boundary if the
- 	 * packet payload is non-zero. The general calculation for
- 	 * padsize would take into account odd header lengths:
- 	 * padsize = (4 - padpos % 4) % 4; However, since only
- 	 * even-length headers are used, padding can only be 0 or 2
- 	 * bytes and we can optimize this a bit. In addition, we must
- 	 * not try to remove padding from short control frames that do
- 	 * not have payload. */
- 	padsize = padpos & 3;
- 	if (padsize && skb->len>=padpos+padsize+FCS_LEN) {
- 		memmove(skb->data + padsize, skb->data, padpos);
- 		skb_pull(skb, padsize);
- 	}
- 
- 	keyix = rx_stats->rs_keyix;
- 
- 	if (!(keyix == ATH9K_RXKEYIX_INVALID) && !decrypt_error &&
- 	    ieee80211_has_protected(fc)) {
- 		rxs->flag |= RX_FLAG_DECRYPTED;
- 	} else if (ieee80211_has_protected(fc)
- 		   && !decrypt_error && skb->len >= hdrlen + 4) {
- 		keyix = skb->data[hdrlen + 3] >> 6;
- 
- 		if (test_bit(keyix, common->keymap))
- 			rxs->flag |= RX_FLAG_DECRYPTED;
- 	}
- 	if (ah->sw_mgmt_crypto &&
- 	    (rxs->flag & RX_FLAG_DECRYPTED) &&
- 	    ieee80211_is_mgmt(fc))
- 		/* Use software decrypt for management frames. */
- 		rxs->flag &= ~RX_FLAG_DECRYPTED;
- }
- 
  /*
   * Run the LNA combining algorithm only in these cases:
   *

Content of type "application/pgp-signature" skipped