1. 03 Jan, 2013 10 commits
  2. 30 Nov, 2012 1 commit
    • Johannes Berg's avatar
      cfg80211: fix BSS struct IE access races · 9caf0364
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      9caf0364
  3. 12 Nov, 2012 1 commit
  4. 18 Oct, 2012 1 commit
  5. 25 Sep, 2012 1 commit
    • Vladimir Kondratiev's avatar
      cfg80211: Fix regulatory check for 60GHz band frequencies · 64629b9d
      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: default avatarVladimir Kondratiev <qca_vkondrat@qca.qualcomm.com>
      Acked-by: default avatarLuis R. Rodriguez <mcgrof@do-not-panic.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      64629b9d
  6. 18 Sep, 2012 2 commits
    • Luis R. Rodriguez's avatar
      cfg80211: fix possible circular lock on reg_regdb_search() · a85d0d7f
      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: default avatarFelix Fietkau <nbd@openwrt.org>
      Tested-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@do-not-panic.com>
      Reviewed-by: default avatarJohannes Berg <johannes@sipsolutions.net>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      a85d0d7f
    • Alan Cox's avatar
      wireless: remove unreachable code · f3baed51
      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: default avatarAlan Cox <alan@linux.intel.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f3baed51
  7. 05 Sep, 2012 1 commit
  8. 02 Aug, 2012 2 commits
  9. 25 Jul, 2012 1 commit
  10. 18 Jul, 2012 1 commit
  11. 17 Jul, 2012 5 commits
  12. 02 Jul, 2012 1 commit
  13. 13 Jun, 2012 1 commit
    • Eliad Peller's avatar
      cfg80211: fix potential deadlock in regulatory · fe20b39e
      Eliad Peller authored
      
      
      reg_timeout_work() calls restore_regulatory_settings() which
      takes cfg80211_mutex.
      
      reg_set_request_processed() already holds cfg80211_mutex
      before calling cancel_delayed_work_sync(reg_timeout),
      so it might deadlock.
      
      Call the async cancel_delayed_work instead, in order
      to avoid the potential deadlock.
      
      This is the relevant lockdep warning:
      
      cfg80211: Calling CRDA for country: XX
      
      ======================================================
      [ INFO: possible circular locking dependency detected ]
      3.4.0-rc5-wl+ #26 Not tainted
      -------------------------------------------------------
      kworker/0:2/1391 is trying to acquire lock:
       (cfg80211_mutex){+.+.+.}, at: [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
      
      but task is already holding lock:
       ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
      
      which lock already depends on the new lock.
      
      the existing dependency chain (in reverse order) is:
      
      -> #2 ((reg_timeout).work){+.+...}:
             [<c008fd44>] validate_chain+0xb94/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c005b600>] wait_on_work+0x4c/0x154
             [<c005c000>] __cancel_work_timer+0xd4/0x11c
             [<c005c064>] cancel_delayed_work_sync+0x1c/0x20
             [<bf28b274>] reg_set_request_processed+0x50/0x78 [cfg80211]
             [<bf28bd84>] set_regdom+0x550/0x600 [cfg80211]
             [<bf294cd8>] nl80211_set_reg+0x218/0x258 [cfg80211]
             [<c03c7738>] genl_rcv_msg+0x1a8/0x1e8
             [<c03c6a00>] netlink_rcv_skb+0x5c/0xc0
             [<c03c7584>] genl_rcv+0x28/0x34
             [<c03c6720>] netlink_unicast+0x15c/0x228
             [<c03c6c7c>] netlink_sendmsg+0x218/0x298
             [<c03933c8>] sock_sendmsg+0xa4/0xc0
             [<c039406c>] __sys_sendmsg+0x1e4/0x268
             [<c0394228>] sys_sendmsg+0x4c/0x70
             [<c0013840>] ret_fast_syscall+0x0/0x3c
      
      -> #1 (reg_mutex){+.+.+.}:
             [<c008fd44>] validate_chain+0xb94/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c04734dc>] mutex_lock_nested+0x48/0x320
             [<bf28b2cc>] reg_todo+0x30/0x538 [cfg80211]
             [<c0059f44>] process_one_work+0x2a0/0x480
             [<c005a4b4>] worker_thread+0x1bc/0x2bc
             [<c0061148>] kthread+0x98/0xa4
             [<c0014af4>] kernel_thread_exit+0x0/0x8
      
      -> #0 (cfg80211_mutex){+.+.+.}:
             [<c008ed58>] print_circular_bug+0x68/0x2cc
             [<c008fb28>] validate_chain+0x978/0x10f0
             [<c0090b68>] __lock_acquire+0x8c8/0x9b0
             [<c0090d40>] lock_acquire+0xf0/0x114
             [<c04734dc>] mutex_lock_nested+0x48/0x320
             [<bf28ae00>] restore_regulatory_settings+0x34/0x418 [cfg80211]
             [<bf28b200>] reg_timeout_work+0x1c/0x20 [cfg80211]
             [<c0059f44>] process_one_work+0x2a0/0x480
             [<c005a4b4>] worker_thread+0x1bc/0x2bc
             [<c0061148>] kthread+0x98/0xa4
             [<c0014af4>] kernel_thread_exit+0x0/0x8
      
      other info that might help us debug this:
      
      Chain exists of:
        cfg80211_mutex --> reg_mutex --> (reg_timeout).work
      
       Possible unsafe locking scenario:
      
             CPU0                    CPU1
             ----                    ----
        lock((reg_timeout).work);
                                     lock(reg_mutex);
                                     lock((reg_timeout).work);
        lock(cfg80211_mutex);
      
       *** DEADLOCK ***
      
      2 locks held by kworker/0:2/1391:
       #0:  (events){.+.+.+}, at: [<c0059e94>] process_one_work+0x1f0/0x480
       #1:  ((reg_timeout).work){+.+...}, at: [<c0059e94>] process_one_work+0x1f0/0x480
      
      stack backtrace:
      [<c001b928>] (unwind_backtrace+0x0/0x12c) from [<c0471d3c>] (dump_stack+0x20/0x24)
      [<c0471d3c>] (dump_stack+0x20/0x24) from [<c008ef70>] (print_circular_bug+0x280/0x2cc)
      [<c008ef70>] (print_circular_bug+0x280/0x2cc) from [<c008fb28>] (validate_chain+0x978/0x10f0)
      [<c008fb28>] (validate_chain+0x978/0x10f0) from [<c0090b68>] (__lock_acquire+0x8c8/0x9b0)
      [<c0090b68>] (__lock_acquire+0x8c8/0x9b0) from [<c0090d40>] (lock_acquire+0xf0/0x114)
      [<c0090d40>] (lock_acquire+0xf0/0x114) from [<c04734dc>] (mutex_lock_nested+0x48/0x320)
      [<c04734dc>] (mutex_lock_nested+0x48/0x320) from [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211])
      [<bf28ae00>] (restore_regulatory_settings+0x34/0x418 [cfg80211]) from [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211])
      [<bf28b200>] (reg_timeout_work+0x1c/0x20 [cfg80211]) from [<c0059f44>] (process_one_work+0x2a0/0x480)
      [<c0059f44>] (process_one_work+0x2a0/0x480) from [<c005a4b4>] (worker_thread+0x1bc/0x2bc)
      [<c005a4b4>] (worker_thread+0x1bc/0x2bc) from [<c0061148>] (kthread+0x98/0xa4)
      [<c0061148>] (kthread+0x98/0xa4) from [<c0014af4>] (kernel_thread_exit+0x0/0x8)
      cfg80211: Calling CRDA to update world regulatory domain
      cfg80211: World regulatory domain updated:
      cfg80211:   (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
      cfg80211:   (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      cfg80211:   (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
      
      Cc: stable@kernel.org
      Signed-off-by: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fe20b39e
  14. 09 Apr, 2012 1 commit
    • Luis R. Rodriguez's avatar
      cfg80211: warn if db.txt is empty with CONFIG_CFG80211_INTERNAL_REGDB · 80007efe
      Luis R. Rodriguez authored
      It has happened twice now where elaborate troubleshooting has
      undergone on systems where CONFIG_CFG80211_INTERNAL_REGDB [0]
      has been set but yet net/wireless/db.txt was not updated.
      
      Despite the documentation on this it seems system integrators could
      use some more help with this, so throw out a kernel warning at boot time
      when their database is empty.
      
      This does mean that the error-prone system integrator won't likely
      realize the issue until they boot the machine but -- it does not seem
      to make sense to enable a build bug breaking random build testing.
      
      [0] http://wireless.kernel.org/en/developers/Regulatory/CRDA#CONFIG_CFG80211_INTERNAL_REGDB
      
      
      
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Youngsin Lee <youngsin@qualcomm.com>
      Cc: Raja Mani <rmani@qca.qualcomm.com>
      Cc: Senthil Kumar Balasubramanian <senthilb@qca.qualcomm.com>
      Cc: Vipin Mehta <vipimeht@qca.qualcomm.com>
      Cc: yahuan@qca.qualcomm.com
      Cc: jjan@qca.qualcomm.com
      Cc: vthiagar@qca.qualcomm.com
      Cc: henrykim@qualcomm.com
      Cc: jouni@qca.qualcomm.com
      Cc: athiruve@qca.qualcomm.com
      Cc: cjkim@qualcomm.com
      Cc: philipk@qca.qualcomm.com
      Cc: sunnykim@qualcomm.com
      Cc: sskwak@qualcomm.com
      Cc: kkim@qualcomm.com
      Cc: mattbyun@qualcomm.com
      Cc: ryanlee@qualcomm.com
      Cc: simbap@qualcomm.com
      Cc: krislee@qualcomm.com
      Cc: conner@qualcomm.com
      Cc: hojinkim@qualcomm.com
      Cc: honglee@qualcomm.com
      Cc: johnwkim@qualcomm.com
      Cc: jinyong@qca.qualcomm.com
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@frijolero.org>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      80007efe
  15. 24 Jan, 2012 1 commit
    • Hong Wu's avatar
      wireless: Save original maximum regulatory transmission power for the... · eccc068e
      Hong Wu authored
      
      wireless: Save original maximum regulatory transmission power for the calucation of the local maximum transmit power
      
      The local maximum transmit power is the maximum power a wireless device
      allowed to transmit. If Power Constraint is presented, the local maximum
      power equals to the maximum allowed power defined in regulatory domain
      minus power constraint.
      
      The maximum transmit power is maximum power a wireless device capable of
      transmitting, and should be used in Power Capability element (7.3.2.16
      IEEE802.11 2007).
      
      The transmit power from a wireless device should not greater than the
      local maximum transmit power.
      
      The maximum transmit power was not calculated correctly in the current
      Linux wireless/mac80211 when Power Constraint is presented.
      Signed-off-by: default avatarHong Wu <hong.wu@dspg.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      eccc068e
  16. 04 Jan, 2012 4 commits
  17. 16 Dec, 2011 2 commits
    • Rajkumar Manoharan's avatar
      cfg80211: Restore orig channel values upon disconnect · 5ce543d1
      Rajkumar Manoharan authored
      
      
      When we restore regulatory settings the world regulatory domain
      is properly reset on cfg80211 (or user prefered regulatory domain)
      but we were never setting back channel values for drivers that use
      WIPHY_FLAG_CUSTOM_REGULATORY. Set these values up again by using
      the orig_ channel parameters.
      
      This fixes restoring custom regulatory settings upon disconnect
      events.
      
      Cc: compat@orbit-lab.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com>
      Signed-off-by: default avatarRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      5ce543d1
    • Luis R. Rodriguez's avatar
      cfg80211: allow following country IE power for custom regdom cards · 061acaae
      Luis R. Rodriguez authored
      
      
      By definition WIPHY_FLAG_STRICT_REGULATORY was intended to allow the
      wiphy to adjust itself to the country IE power information if the
      card had no regulatory data but we had no way to tell cfg80211 that if
      the card also had its own custom regulatory domain (these are typically
      custom world regulatory domains) that we want to follow the country IE's
      noted values for power for each channel. We add support for this and
      document it.
      
      This is not a critical fix but a performance optimization for cards
      with custom regulatory domains that associate to an AP with sends
      out country IEs with a higher EIRP than the one on the custom
      regulatory domain. In practice the only driver affected right now
      are the Atheros drivers as they are the only drivers using both
      WIPHY_FLAG_STRICT_REGULATORY and WIPHY_FLAG_CUSTOM_REGULATORY --
      used on cards that have an Atheros world regulatory domain. Cards
      that have been programmed to follow a country specifically will not
      follow the country IE power. So although not a stable fix distributions
      should consider cherry picking this.
      
      Cc: compat@orbit-lab.org
      Cc: Paul Stewart <pstew@google.com>
      Cc: Rajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Cc: Senthilkumar Balasubramanian <senthilb@qca.qualcomm.com>
      Reported-by: default avatarRajkumar Manoharan <rmanohar@qca.qualcomm.com>
      Signed-off-by: default avatarLuis R. Rodriguez <mcgrof@qca.qualcomm.com>
      Signed-off-by: default avatarJohn W. Linville <linville@tuxdriver.com>
      061acaae
  18. 13 Dec, 2011 1 commit
  19. 30 Nov, 2011 2 commits
  20. 21 Nov, 2011 1 commit