linux-stable.git/net/wireless/reg.c, branch linux-3.9.y

wireless: regulatory: fix channel disabling race condition

2013-05-08T03:33:13+00:00

commit 990de49f74e772b6db5208457b7aa712a5f4db86 upstream.

When a full scan 2.4 and 5 GHz scan is scheduled, but then the 2.4 GHz
part of the scan disables a 5.2 GHz channel due to, e.g. receiving
country or frequency information, that 5.2 GHz channel might already
be in the list of channels to scan next. Then, when the driver checks
if it should do a passive scan, that will return false and attempt an
active scan. This is not only wrong but can also lead to the iwlwifi
device firmware crashing since it checks regulatory as well.

Fix this by not setting the channel flags to just disabled but rather
OR'ing in the disabled flag. That way, even if the race happens, the
channel will be scanned passively which is still (mostly) correct.

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

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem

2013-02-18T18:47:13+00:00

Conflicts:
	drivers/net/wireless/iwlwifi/dvm/tx.c
	drivers/net/wireless/ti/wlcore/sdio.c
	drivers/net/wireless/ti/wlcore/spi.c

cfg80211: allow drivers to selectively disable 80/160 MHz

2013-02-15T08:41:38+00:00

Some drivers might support 80 or 160 MHz only on some
channels for whatever reason, so allow them to disable
these channel widths. Also maintain the new flags when
regulatory bandwidth limitations would disable these
wide channels.

Reviewed-by: Luis R. Rodriguez 
Signed-off-by: Johannes Berg

nl80211/cfg80211: add radar detection command/event

2013-02-15T08:40:18+00:00

Add new NL80211_CMD_RADAR_DETECT, which starts the Channel
Availability Check (CAC). This command will also notify the
usermode about events (CAC finished, CAC aborted, radar
detected, NOP finished).
Once radar detection has started it should continuously
monitor for radars as long as the channel is active.

This patch enables DFS for AP mode in nl80211/cfg80211.

Based on original patch by Victor Goldenshtein 

Signed-off-by: Simon Wunderlich 
[remove WIPHY_FLAG_HAS_RADAR_DETECT again -- my mistake]
Signed-off-by: Johannes Berg

cfg80211: Fix memory leak

2013-02-11T17:44:41+00:00

When a driver requests a specific regulatory domain after cfg80211 already
has one, a struct ieee80211_regdomain is leaked.

Reported-by: Larry Finger 
Tested-by: Larry Finger 
Signed-off-by: Larry Finger 
Signed-off-by: Johannes Berg

Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless-next into for-davem

2013-01-28T19:43:00+00:00

wireless: fix regulatory HT40 allowed check

2013-01-11T13:32:20+00:00

commit 1a9193185f462a51815fe48491f8a6fb6b942551 "regulatory: code cleanup"
changed is_ht40_allowed without considering that IEEE80211_CHAN_NO_HT40 is
not just one flag, but two.
This is causing HT40- to be blocked completely.

Signed-off-by: Felix Fietkau 
Signed-off-by: Johannes Berg

regulatory: fix restore_regulatory_settings

2013-01-09T11:19:52+00:00

My commit 379b82f4c9dc6e67bf61aa61b096c06a2f320f60
("regulatory: pass new regdomain to reset function")
broke the restore_regulatory_settings() function due
to a logic change. Consider this change:

-	reset_regdomains(true);
-	cfg80211_regdomain = cfg80211_world_regdom;
+	reset_regdomains(true, cfg80211_world_regdom);

This looks innocent enough, until you realise that the
called function (reset_regdomains) also resets the
cfg80211_world_regdom pointer, so that the old version
of the code would use the new object it pointed to and
the new version of the code uses the old object. This
lead to a double-free of this object.

Since reset_regdomains() sets it to &world_regdom, use
that directly.

Reported-by: Sujith Manoharan 
Tested-by: Sujith Manoharan 
Reported-by: Bob Copeland 
Reported-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg

regulatory: fix uevent

2013-01-09T11:19:43+00:00

The uevent callback doesn't protect its access to
last_request, which now causes a warning since
the conversion to get_last_request(). Fix this by
allowing to use RCU protection for last_request.

Reported-by: Emmanuel Grumbach 
Signed-off-by: Johannes Berg

cfg80211: move world roaming check for beacon hints

2013-01-03T12:01:38+00:00

We should not add new beacon hints even if the wiphy
is not world roaming. Without this we were always adding
a beacon hint if not world roaming for every non world
roaming wiphy interface.

Tested-by: Ben Greear 
Reported-by: Ben Greear 
Reported-by: Johannes Berg 
Signed-off-by: Luis R. Rodriguez 
[fix locking]
Signed-off-by: Johannes Berg