linux/net/mac80211, branch v3.9.4

mac80211: use synchronize_rcu() with rcu_barrier()

2013-05-08T03:33:05Z

commit 8ceb59557bdc373e532b87d4142ce27e04218f0e upstream. The RCU docs used to state that rcu_barrier() included a wait for an RCU grace period; however the comments for rcu_barrier() as of commit f0a0e6f... "rcu: Clarify memory-ordering properties of grace-period primitives" contradict this. So add back synchronize_{rcu,net}() to where they once were, but keep the rcu_barrier()s for the call_rcu() callbacks. Signed-off-by: Bob Copeland Reviewed-by: Paul E. McKenney Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

mac80211: fix station entry leak/warning while suspending

2013-05-08T03:33:04Z

commit b20d34c458bc2bbd0a4624f2933581e01e72d875 upstream. Since Stanislaw's patches, when suspending while connected, cfg80211 will disconnect. This causes the AP station to be removed, which uses call_rcu() to clean up. Due to needing process context, this queues a work struct on the mac80211 workqueue. This will warn and fail when already suspended, which can happen if the rcu call doesn't happen quickly. To fix this, replace the synchronize_net() which is really just synchronize_rcu_expedited() with rcu_barrier(), which unlike synchronize_rcu() waits until RCU callback have run and thus avoids this issue. In theory, this can even happen without Stanislaw's change to disconnect on suspend since userspace might disconnect just before suspending, though then it's unlikely that the call_rcu() will be delayed long enough. Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman

Merge branch 'for-john' of git://x-git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211

2013-04-12T17:20:51Z

mac80211: fix cfg80211 interaction on auth/assoc request

2013-04-10T19:38:36Z

If authentication (or association with FT) is requested by userspace, mac80211 currently doesn't tell cfg80211 that it disconnected from the AP. That leaves inconsistent state: cfg80211 thinks it's connected while mac80211 thinks it's not. Typically this won't last long, as soon as mac80211 reports the new association to cfg80211 the old one goes away. If, however, the new authentication or association doesn't succeed, then cfg80211 will forever think the old one still exists and will refuse attempts to authenticate or associate with the AP it thinks it's connected to. Anders reported that this leads to it taking a very long time to reconnect to a network, or never even succeeding. I tested this with an AP hacked to never respond to auth frames, and one that works, and with just those two the system never recovers because one won't work and cfg80211 thinks it's connected to the other so refuses connections to it. To fix this, simply make mac80211 tell cfg80211 when it is no longer connected to the old AP, while authenticating or associating to a new one. Cc: stable@vger.kernel.org Reported-by: Anders Kaseorg Signed-off-by: Johannes Berg

Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211

2013-04-08T18:30:26Z

mac80211: fix LED in idle handling

2013-04-08T11:12:05Z

feng xiangjun reports that my commit 382a103b2b528a3085cde4ac56fc69d92a828b72 Author: Johannes Berg Date: Fri Mar 22 22:30:09 2013 +0100 mac80211: fix idle handling sequence broke the wireless status LED. The reason is that we now call ieee80211_idle_off() when the channel context is assigned, and that doesn't recalculate the LED state. Fix this by making that function a wrapper around most of idle recalculation while forcing active. Reported-by: feng xiangjun Tested-by: feng xiangjun Signed-off-by: Johannes Berg

Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211

2013-04-01T19:09:28Z

Merge branch 'for-john' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211

2013-03-25T18:50:17Z

mac80211: fix idle handling sequence

2013-03-25T15:50:18Z

Corey Richardson reported that my idle handling cleanup (commit fd0f979a1b, "mac80211: simplify idle handling") broke ath9k_htc. The reason appears to be that it wants to go out of idle before switching channels. To fix it, reimplement that sequence. Reported-by: Corey Richardson Signed-off-by: Johannes Berg

mac80211: fix remain-on-channel cancel crash

2013-03-25T12:50:33Z

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. Cc: stable@vger.kernel.org [3.6+] Reported-by: Jouni Malinen Tested-by: Jouni Malinen Signed-off-by: Johannes Berg