linux-stable.git/net/mac80211, branch v3.8.7

mac80211: fix remain-on-channel cancel crash

2013-04-12T16:52:07+00:00

commit 3fbd45ca8d1c98f3c2582ef8bc70ade42f70947b upstream.

If a ROC item is canceled just as it expires, the work
struct may be scheduled while it is running (and waiting
for the mutex). This results in it being run after being
freed, which obviously crashes.

To fix this don't free it when aborting is requested but
instead mark it as "to be freed", which makes the work a
no-op and allows freeing it outside.

Reported-by: Jouni Malinen 
Tested-by: Jouni Malinen 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: prevent spurious HT/VHT downgrade message

2013-04-05T16:26:01+00:00

commit 586e01ededf9b713a1512dd658806791a7ca1a50 upstream.

Even when connecting to an AP that doesn't support VHT,
and even when the local device doesn't support it either,
the downgrade message gets printed. Suppress the message
if HT and/or VHT is disabled.

Signed-off-by: Johannes Berg 
Cc: Andrew Lutomirski 
Signed-off-by: Greg Kroah-Hartman

mac80211: always synchronize_net() during station removal

2013-04-05T16:25:49+00:00

commit 27a737ff7cb062fb9cbceba9b44d60aa74862bfa upstream.

If there are keys left during station removal, then a
synchronize_net() will be done (for each key, I have a
patch to address this for 3.10), otherwise it won't be
done at all which causes issues because the station
could be used for TX while it's being removed from the
driver -- that might confuse the driver.

Fix this by always doing synchronize_net() if no key
was present any more.

Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: Fix crash due to un-canceled work-items

2013-03-14T18:26:25+00:00

commit 499218595a2e8296b7492af32fcca141b7b8184a upstream.

Some mlme work structs are not cancelled on disassociation
nor interface deletion, which leads to them running after
the memory has been freed

There is not a clean way to cancel these in the disassociation
logic because they must be canceled outside of the ifmgd->mtx
lock, so just cancel them in mgd_stop logic that tears down
the station.

This fixes the crashes we see in 3.7.9+.  The crash stack
trace itself isn't so helpful, but this warning gives
more useful info:

WARNING: at /home/greearb/git/linux-3.7.dev.y/lib/debugobjects.c:261 debug_print_object+0x7c/0x8d()
ODEBUG: free active (active state 0) object type: work_struct hint: ieee80211_sta_monitor_work+0x0/0x14 [mac80211]
Modules linked in: [...]
Pid: 14743, comm: iw Tainted: G         C O 3.7.9+ #11
Call Trace:
 [] warn_slowpath_common+0x80/0x98
 [] warn_slowpath_fmt+0x41/0x43
 [] debug_print_object+0x7c/0x8d
 [] debug_check_no_obj_freed+0x95/0x1c3
 [] slab_free_hook+0x70/0x79
 [] kfree+0x62/0xb7
 [] netdev_release+0x39/0x3e
 [] device_release+0x52/0x8a
 [] kobject_release+0x121/0x158
 [] kobject_put+0x4c/0x50
 [] netdev_run_todo+0x25c/0x27e

Signed-off-by: Ben Greear 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: always unblock CSA queue stop when disconnecting

2013-02-28T13:38:41+00:00

Commit 5b36ebd8249f403c7edf7cf68d68e9a0d0f55243 upstream.

In some cases when disconnecting after (or during?) CSA
the queues might not recover, and then the only way to
recover is reloading the module.

Fix this by always unblocking the queue CSA reason when

disconnecting.

Reported-by: Jan-Michael Brummer 
Signed-off-by: Johannes Berg 
Signed-off-by: Greg Kroah-Hartman

mac80211: fix channel selection bug

2013-02-11T10:12:26+00:00

When trying to connect to an AP that advertises HT but not
VHT, the mac80211 code erroneously uses the configuration
from the AP as is instead of checking it against regulatory
and local capabilities. This can lead to using an invalid
or even inexistent channel (like 11/HT40+).

Additionally, the return flags from downgrading must be
ORed together, to collect them from all of the downgrades.
Also clarify the message.

Signed-off-by: Johannes Berg

mac80211: fix managed mode channel context use

2013-02-07T19:56:01+00:00

My commit f2d9d270c15ae0139b54a7e7466d738327e97e03
("mac80211: support VHT association") introduced a
very stupid bug: the loop to downgrade the channel
width never attempted to actually use it again so
it would downgrade all the way to 20_NOHT. Fix it.

Signed-off-by: Johannes Berg

mac80211: fix error in sizeof() usage

2013-02-06T16:31:55+00:00

Using 'sizeof' on array given as function argument returns
size of a pointer rather than the size of array.

Cc: stable@vger.kernel.org
Signed-off-by: Cong Ding 
Signed-off-by: Johannes Berg

mac80211: add encrypt headroom to PERR frames

2013-01-16T22:24:51+00:00

Mesh PERR action frames are robust and thus may be encrypted, so add
proper head/tailroom to allow this.  Fixes this warning when operating
a Mesh STA on ath5k:

WARNING: at net/mac80211/wpa.c:427 ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]()
Call Trace:
 [] warn_slowpath_common+0x63/0x78
 [] warn_slowpath_null+0xf/0x13
 [] ccmp_encrypt_skb.isra.5+0x7b/0x1a0 [mac80211]
 [] ieee80211_crypto_ccmp_encrypt+0x1f/0x37 [mac80211]
 [] invoke_tx_handlers+0xcad/0x10bd [mac80211]
 [] ieee80211_tx+0x87/0xb3 [mac80211]
 [] ieee80211_tx_pending+0xcc/0x170 [mac80211]
 [] tasklet_action+0x3e/0x65

Signed-off-by: Bob Copeland 
Signed-off-by: Johannes Berg

mac80211: set NEED_TXPROCESSING for PERR frames

2013-01-16T22:22:21+00:00

A user reported warnings in ath5k due to transmitting frames with no
rates set up.  The frames were Mesh PERR frames, and some debugging
showed an empty control block with just the vif pointer:

>  [  562.522682] XXX txinfo: 00000000: 00 00 00 00 00 00 00 00 00 00 00
>  00 00 00 00 00  ................
>  [  562.522688] XXX txinfo: 00000010: 00 00 00 00 00 00 00 00 54 b8 f2
>  db 00 00 00 00  ........T.......
>  [  562.522693] XXX txinfo: 00000020: 00 00 00 00 00 00 00 00 00 00 00
>  00 00 00 00 00  ................

Set the IEEE80211_TX_INTFL_NEED_TXPROCESSING flag to ensure that
rate control gets run before the frame is sent.

Signed-off-by: Bob Copeland 
Signed-off-by: Johannes Berg