An error occurred fetching the project authors.
- 06 Mar, 2013 1 commit
-
-
Johannes Berg authored
For VHT, the wider bandwidths (up to 160 MHz) need to be allowed. Since world roaming only covers the case of connecting to an AP, it can be opened up there, we will rely on the AP to know the local regulations. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 15 Feb, 2013 2 commits
-
-
Johannes Berg authored
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 <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Simon Wunderlich authored
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 <victorg@ti.com> Signed-off-by:
Simon Wunderlich <siwu@hrz.tu-chemnitz.de> [remove WIPHY_FLAG_HAS_RADAR_DETECT again -- my mistake] Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 11 Feb, 2013 1 commit
-
-
Larry Finger authored
When a driver requests a specific regulatory domain after cfg80211 already has one, a struct ieee80211_regdomain is leaked. Reported-by:
Larry Finger <Larry.Finger@lwfinger.net> Tested-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 11 Jan, 2013 1 commit
-
-
Felix Fietkau authored
commit 1a919318 "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 <nbd@openwrt.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 09 Jan, 2013 2 commits
-
-
Johannes Berg authored
My commit 379b82f4 ("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 <sujith@msujith.org> Tested-by:
Sujith Manoharan <sujith@msujith.org> Reported-by:
Bob Copeland <me@bobcopeland.com> Reported-by:
Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
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 <emmanuel.grumbach@intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 03 Jan, 2013 26 commits
-
-
Luis R. Rodriguez authored
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 <greearb@candelatech.com> Reported-by:
Ben Greear <greearb@candelatech.com> Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> [fix locking] Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Luis R. Rodriguez authored
This will be used later by other code. This has no functional change. Tested-by:
Ben Greear <greearb@candelatech.com> Reported-by:
Ben Greear <greearb@candelatech.com> Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Luis R. Rodriguez authored
Regulatory beacon hints are used to help with world roaming and as it is right now we learn from a beacon hint processed on one wiphy to all other wiphys. The processing of beacon hints however is scheduled and if we have a lot of interfaces we may hit the case that we'll queue a the same beacon hint many times until its processed. To avoid this do a lookup on the queued up beacon hints prior to adding a new beacon hint. If the beacon hint is removed from the pending reg beacon hint list then it would be processed and we'd ensure all wiphys would have learned from it, if its on the pending reg beacon list we'd now find it prior to it being processed. Tested-by:
Ben Greear <greearb@candelatech.com> Reported-by:
Ben Greear <greearb@candelatech.com> Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Instead of returning an error and filling a pointer return the pointer and an ERR_PTR value in error cases. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This will allow making freq_reg_info() lock-free. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
To simplify the locking and not require cfg80211_mutex (which nl80211 uses to access the global regdomain) and also to make it possible for drivers to access their wiphy->regd safely, use RCU to protect these pointers. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Instead of assigning after calling the function do it inside the function. This will later avoid a period of time where the pointer is NULL. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The channel bandwidth handling isn't really quite right, it assumes that a 40 MHz channel is really two 20 MHz channels, which isn't strictly true. This is the way the regulatory database handling is defined right now though so remove the logic to handle other channel widths. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's a bug with the world regulatory domain, it can be updated any time which is different from all other regdomains that can only be updated once after a request for them. Fix this by adding a check for "processed" to the reg_is_valid_request() function and clear that when doing a request. While looking at this I also found another locking bug, last_request is protected by the reg_mutex not the cfg80211_mutex so the code in nl80211 is racy. Remove that code as it only tries to prevent an allocation in an error case, which isn't necessary. Then the function can also become static and locking in nl80211 can have a smaller scope. Also change __set_regdom() to do the checks earlier and not different for world/other regdomains. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
wiphy_apply_custom_regulatory() doesn't have to hold the regulatory mutex as it only modifies the given wiphy with the given regulatory domain, it doesn't access any global regulatory data. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Many places that currently check that cfg80211_mutex is held don't actually use any data protected by it. The functions that need to hold the cfg80211_mutex are the ones using the cfg80211_regdomain variable, so add the lock assertion to those and clarify this in the comments. The reason for this is that nl80211 uses the regdom without being able to hold reg_mutex. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
The function itself has dual-purpose: it can retrieve from a given regdomain or from the globally installed one. Change it to have a single purpose only: to look up from a given regdomain. Pass the correct regdomain in the freq_reg_info() function instead. This also changes the locking rules for it, no locking is required any more. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Even if it never happens and is hidden behind the debug config option, it's completely useless: the calltrace will only show module loading. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
toupper() only modifies lower-case letters, so the isalpha() check is redundant; remove it. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Use list_splice_tail_init() and also simplify the locking. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This code is a bit too BUG_ON happy, remove all instances and while doing so make some code a bit smarter by passing the right pointer instead of indices into arrays. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
This is pretty much useless since get_wiphy_idx() always returns true since it's always called with a valid wiphy pointer. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Instead of treating special error codes specially, like -EALREADY, introduce a real enum for all the needed possibilities and use it. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
It would be a major problem if anything were to run concurrently while the module is being unloaded so remove the locking that doesn't help anything. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Clean up various things like indentation, extra parentheses, too many/few line breaks, etc. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's no need to unlock before calling queue_regulatory_request(), so simplify the function. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's no need to test whether a list is empty or not before iterating. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
Use ERR_PTR/IS_ERR to return the result or errors, also do some code cleanups. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
As the dummy_rule (also renamed from irule) is only used for output by the reg_rules_intersect() function there's no need to clear it at all, remove that. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
There's no need to allocate one reg rule more than will be used, reduce the allocations. The allocation in nl80211 already doesn't allocate too much space. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Johannes Berg authored
When intersecting rules, we count first to know how many rules need to be allocated, and then do the intersection into the allocated array. However, the code doing this writes past the end of the array because it attempts to do all intersections. Make it stop when the right number of rules has been reached. Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 22 Dec, 2012 1 commit
-
-
Greg KH authored
CONFIG_HOTPLUG is always enabled now, so remove the unused code that was trying to be compiled out when this option was disabled, in the networking core. Cc: Bill Pemberton <wfp5p@virginia.edu> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by:
David S. Miller <davem@davemloft.net>
-
- 30 Nov, 2012 1 commit
-
-
Johannes Berg authored
When a BSS struct is updated, the IEs are currently overwritten or freed. This can lead to races if some other CPU is accessing the BSS struct and using the IEs concurrently. Fix this by always allocating the IEs in a new struct that holds the data and length and protecting access to this new struct with RCU. Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 12 Nov, 2012 1 commit
-
-
Johannes Berg authored
When in world roaming mode, allow 40 MHz to be used on channels 12 and 13 so that an AP that is, e.g., using HT40+ on channel 9 (in the UK) can be used. Cc: stable@vger.kernel.org Reported-by:
Eddie Chapman <eddie@ehuk.net> Tested-by:
Eddie Chapman <eddie@ehuk.net> Acked-by:
Luis R. Rodriguez <mcgrof@qca.qualcomm.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 18 Oct, 2012 1 commit
-
-
Felix Fietkau authored
A few places touch chan->max_power based on updated tx power rules, but forget to do the same to chan->max_reg_power. Signed-off-by:
Felix Fietkau <nbd@openwrt.org> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 25 Sep, 2012 1 commit
-
-
Vladimir Kondratiev authored
The current regulatory code on cfg80211 performs a check to see if a regulatory rule belongs to an IEEE band so that if a Country IE is received and no rules are specified for a band (which is allowed by IEEE) those bands are left intact. The current band check assumes a rule is bound to a band if the rule's start or end frequency is less than 2 GHz apart from the center of frequency being inspected. In order to support 60 GHz for 802.11ad we need to increase this to account for the channel spacing of 2160 MHz whereby a channel somewhere in the middle of a regulatory rule may be more than 2 GHz apart from either the beginning or end of the frequency rule. Without a fix for this even though channels 1-3 are allowed world wide on the rule (57240 - 63720 @ 2160), channel 2 at 60480 MHz will end up getting disabled given that it is 3240 MHz from both the frequency rule start and end frequency. Fix this by using 2 GHz separation assumption for the 2.4 and 5 GHz bands but for 60 GHz use a 10 GHz separation before assuming a rule is not part of the band. Since we have no 802.11ad drivers yet merged this change has no impact to existing Linux upstream device drivers. Signed-off-by:
Vladimir Kondratiev <qca_vkondrat@qca.qualcomm.com> Acked-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 19 Sep, 2012 1 commit
-
-
Luis R. Rodriguez authored
When call_crda() is called we kick off a witch hunt search for the same regulatory domain on our internal regulatory database and that work gets kicked off on a workqueue, this is done while the cfg80211_mutex is held. If that workqueue kicks off it will first lock reg_regdb_search_mutex and later cfg80211_mutex but to ensure two CPUs will not contend against cfg80211_mutex the right thing to do is to have the reg_regdb_search() wait until the cfg80211_mutex is let go. The lockdep report is pasted below. cfg80211: Calling CRDA to update world regulatory domain ====================================================== [ INFO: possible circular locking dependency detected ] 3.3.8 #3 Tainted: G O ------------------------------------------------------- kworker/0:1/235 is trying to acquire lock: (cfg80211_mutex){+.+...}, at: [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] but task is already holding lock: (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211] which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #2 (reg_regdb_search_mutex){+.+...}: [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<81645778>] is_world_regdom+0x9f8/0xc74 [cfg80211] -> #1 (reg_mutex#2){+.+...}: [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<8164539c>] is_world_regdom+0x61c/0xc74 [cfg80211] -> #0 (cfg80211_mutex){+.+...}: [<800a77b8>] __lock_acquire+0x10d4/0x17bc [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] other info that might help us debug this: Chain exists of: cfg80211_mutex --> reg_mutex#2 --> reg_regdb_search_mutex Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(reg_regdb_search_mutex); lock(reg_mutex#2); lock(reg_regdb_search_mutex); lock(cfg80211_mutex); *** DEADLOCK *** 3 locks held by kworker/0:1/235: #0: (events){.+.+..}, at: [<80089a00>] process_one_work+0x230/0x460 #1: (reg_regdb_work){+.+...}, at: [<80089a00>] process_one_work+0x230/0x460 #2: (reg_regdb_search_mutex){+.+...}, at: [<81646828>] set_regdom+0x710/0x808 [cfg80211] stack backtrace: Call Trace: [<80290fd4>] dump_stack+0x8/0x34 [<80291bc4>] print_circular_bug+0x2ac/0x2d8 [<800a77b8>] __lock_acquire+0x10d4/0x17bc [<800a8384>] lock_acquire+0x60/0x88 [<802950a8>] mutex_lock_nested+0x54/0x31c [<816468a4>] set_regdom+0x78c/0x808 [cfg80211] Reported-by:
Felix Fietkau <nbd@openwrt.org> Tested-by:
Felix Fietkau <nbd@openwrt.org> Cc: stable@vger.kernel.org Signed-off-by:
Luis R. Rodriguez <mcgrof@do-not-panic.com> Reviewed-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
John W. Linville <linville@tuxdriver.com>
-
- 18 Sep, 2012 1 commit
-
-
Alan Cox authored
The only case where intersected_rd can become non NULL is within an if. All paths from that if return, so the end chunk has therefore squawked its last and is no more. Signed-off-by:
Alan Cox <alan@linux.intel.com> Signed-off-by:
Johannes Berg <johannes.berg@intel.com>
-