linux.git/net/mac80211, branch v3.17-rc2

mac80211: fix channel switch for chanctx-based drivers

2014-08-22T21:45:49+00:00

The new_ctx pointer is set only for non-chanctx drivers.  This yielded a
crash for chanctx-based drivers during channel switch finalization:

  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020
  IP: ieee80211_vif_use_reserved_switch+0x71c/0xb00 [mac80211]

Use an adequate chanctx pointer to fix this.

Reported-by: Linus Torvalds 
Signed-off-by: Michal Kazior 
Signed-off-by: Linus Torvalds

Merge tag 'master-2014-07-25' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next

2014-07-29T00:36:25+00:00

John W. Linville says:

====================
pull request: wireless-next 2014-07-25

Please pull this batch of updates intended for the 3.17 stream!

For the mac80211 bits, Johannes says:

"We have a lot of TDLS patches, among them a fix that should make hwsim
tests happy again. The rest, this time, is mostly small fixes."

For the Bluetooth bits, Gustavo says:

"Some more patches for 3.17. The most important change here is the move of
the 6lowpan code to net/6lowpan. It has been agreed with Davem that this
change will go through the bluetooth tree. The rest are mostly clean up and
fixes."

and,

"Here follows some more patches for 3.17. These are mostly fixes to what
we've sent to you before for next merge window."

For the iwlwifi bits, Emmanuel says:

"I have the usual amount of BT Coex stuff. Arik continues to work
on TDLS and Ariej contributes a few things for HS2.0. I added a few
more things to the firmware debugging infrastructure. Eran fixes a
small bug - pretty normal content."

And for the Atheros bits, Kalle says:

"For ath6kl me and Jessica added support for ar6004 hw3.0, our latest
version of ar6004.

For ath10k Janusz added a printout so that it's easier to check what
ath10k kconfig options are enabled. He also added a debugfs file to
configure maximum amsdu and ampdu values. Also we had few fixes as
usual."

On top of that is the usual large batch of various driver updates --
brcmfmac, mwifiex, the TI drivers, and wil6210 all get some action.
Rafał has also been very busy with b43 and related updates.

Also, I pulled the wireless tree into this in order to resolve a
merge conflict...

P.S.  The change to fs/compat_ioctl.c reflects a name change in a
Bluetooth header file...
====================

Signed-off-by: David S. Miller

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless

2014-07-25T14:22:36+00:00

Conflicts:
	net/mac80211/cfg.c

Signed-off-by: John W. Linville

mac80211: fix crash on getting sta info with uninitialized rate control

2014-07-22T20:17:17+00:00

If the expected throughput is queried before rate control has been
initialized, the minstrel op for it will crash while trying to access
the rate table.
Check for WLAN_STA_RATE_CONTROL before attempting to use the rate
control op.

Reported-by: Jean-Pierre Tosoni 
Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg

Merge git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next

2014-07-22T17:49:34+00:00

mac80211: add support for Rx reordering offloading

2014-07-21T15:42:07+00:00

Some drivers may be performing most of Tx/Rx
aggregation on their own (e.g. in firmware)
including AddBa/DelBa negotiations but may
otherwise require Rx reordering assistance.

The patch exports 2 new functions for establishing
Rx aggregation sessions in assumption device
driver has taken care of the necessary
negotiations.

Signed-off-by: Michal Kazior 
[fix endian bug]
Signed-off-by: Johannes Berg

mac80211: fix Rx reordering with RX_FLAG_AMSDU_MORE

2014-07-21T14:17:26+00:00

Some drivers (e.g. ath10k) report A-MSDU subframes
individually with identical seqno. The A-MPDU Rx
reorder code did not account for that which made
it practically unusable with drivers using
RX_FLAG_AMSDU_MORE because it would end up
dropping a lot of frames resulting in confusion in
upper network transport layers.

Signed-off-by: Michal Kazior 
Signed-off-by: Johannes Berg

mac80211: remove useless NULL checks

2014-07-21T14:04:27+00:00

sdata can't be NULL, and key being NULL is really not possible
unless the code is modified.

The sdata check made a static analyze (klocwork) unhappy because
we would get pointer to local (sdata->local) and only then check
if sdata is non-NULL.

Signed-off-by: Eytan Lifshitz 
Signed-off-by: Emmanuel Grumbach 
[remove !key check as well]
Signed-off-by: Johannes Berg

mac80211: fix a potential NULL access in ieee80211_crypto_hw_decrypt

2014-07-21T10:34:08+00:00

The NULL pointer access could happen when ieee80211_crypto_hw_decrypt
is called from ieee80211_rx_h_decrypt with the following condition:
1. rx->key->conf.cipher is not WEP, CCMP, TKIP or AES_CMAC
2. rx->sta is NULL

When ieee80211_crypto_hw_decrypt is called, it verifies
rx->sta->cipher_scheme and it will cause Oops if rx->sta is NULL.

This path adds an addirional rx->sta == NULL verification in
ieee80211_crypto_hw_decrypt for this case.

Signed-off-by: Max Stepanov 
Signed-off-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg

mac80211: remove redundant IEEE80211_STA_CSA_RECEIVED flag

2014-07-21T10:21:26+00:00

The csa_active flag was added in sdata a while ago and made
IEEE80211_STA_CSA_RECEIVED redundant.  The new flag is also used to
mark when CSA is ongoing on other iftypes and took over the old one as
the preferred method for checking whether we're in the middle of a
channel switch.  Remove the old, redundant flag.

Signed-off-by: Luciano Coelho 
Signed-off-by: Johannes Berg