1. 19 12月, 2013 3 次提交
    • J
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg 提交于
      The scan code creates an iflist_mtx -> mtx locking dependency,
      and a few other places, notably radar detection, were creating
      the opposite dependency, causing lockdep to complain. As scan
      and radar detection are mutually exclusive, the deadlock can't
      really happen in practice, but it's still bad form.
      
      A similar issue exists in the monitor mode code, but this is
      only used by channel-context drivers right now and those have
      to have hardware scan, so that also can't happen.
      
      Still, fix these issues by making some of the channel context
      code require the mtx to be held rather than acquiring it, thus
      allowing the monitor/radar callers to keep the iflist_mtx->mtx
      lock ordering.
      
      While at it, also fix access to the local->scanning variable
      in the radar code, and document that radar_detect_enabled is
      now properly protected by the mtx.
      
      All this would now introduce an ABBA deadlock between the DFS
      work cancelling and local->mtx, so change the locking there a
      bit to not need to use cancel_delayed_work_sync() but be able
      to just use cancel_delayed_work(). The work is also safely
      stopped/removed when the interface is stopped, so no extra
      changes are needed.
      Reported-by: NKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      34a3740d
    • J
      mac80211: remove unnecessary iflist_mtx locking · 6924d013
      Johannes Berg 提交于
      The radar detection code changed a few times, and due to
      the changes some iflist_mtx locking stayed in that isn't
      actually necessary - remove it.
      
      One version of the code needed it because an AP interface's
      VLAN list was changed to use this, but then we moved the
      list handling outside of the chanctx handling and thus the
      locking was no longer needed.
      Tested-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6924d013
    • J
      mac80211: align struct ps_data.tim to unsigned long · 5fe2bb86
      Joe Perches 提交于
      Its address is used as an unsigned long *, so make sure
      that the tim u8 array is properly aligned.
      
      Signed-off-by: Joe Perches <joe@perches.com
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5fe2bb86
  2. 18 12月, 2013 2 次提交
  3. 16 12月, 2013 17 次提交
  4. 11 12月, 2013 2 次提交
  5. 10 12月, 2013 1 次提交
  6. 09 12月, 2013 1 次提交
  7. 08 12月, 2013 1 次提交
  8. 06 12月, 2013 7 次提交
    • J
      Bluetooth: Fix valid LE PSM check · c8afe8d0
      Johan Hedberg 提交于
      The range of valid LE PSMs is 0x0001-0x00ff so the check should be for
      "less than or equal to" instead of "less than".
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      c8afe8d0
    • J
      Bluetooth: Use min_t for calculating chan->mps · f1324ea5
      Johan Hedberg 提交于
      Since there's a nice convenient helper for calculating the minimum of
      two values, let's use that one.
      Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      f1324ea5
    • S
      mac80211: fix nested sdata lock for IBSS/CSA · bafdc614
      Simon Wunderlich 提交于
      This fixes a regression introduced by my patch "mac80211: don't cancel
      csa finalize work within stop_ap", which added sdata locks to
      ieee80211_csa_finalize_work() without removing the locking for
      ieee80211_ibss_finish_csa(), which is called by the former, resulting
      in a deadlock due to nested locking.
      Signed-off-by: NSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bafdc614
    • E
      cfg80211: don't "leak" uncompleted scans · 4a58e7c3
      Eliad Peller 提交于
      ___cfg80211_scan_done() can be called in some cases
      (e.g. on NETDEV_DOWN) before the low level driver
      notified scan completion (which is indicated by
      passing leak=true).
      
      Clearing rdev->scan_req in this case is buggy, as
      scan_done_wk might have already being queued/running
      (and can't be flushed as it takes rtnl()).
      
      If a new scan will be requested at this stage, the
      scan_done_wk will try freeing it (instead of the
      previous scan), and this will later result in
      a use after free.
      
      Simply remove the "leak" option, and replace it with
      a standard WARN_ON.
      
      An example backtrace after such crash:
      Unable to handle kernel paging request at virtual address fffffee5
      pgd = c0004000
      [fffffee5] *pgd=9fdf6821, *pte=00000000, *ppte=00000000
      Internal error: Oops: 17 [#1] SMP ARM
      PC is at cfg80211_scan_done+0x28/0xc4 [cfg80211]
      LR is at __ieee80211_scan_completed+0xe4/0x2dc [mac80211]
      [<bf0077b0>] (cfg80211_scan_done+0x28/0xc4 [cfg80211])
      [<bf0973d4>] (__ieee80211_scan_completed+0xe4/0x2dc [mac80211])
      [<bf0982cc>] (ieee80211_scan_work+0x94/0x4f0 [mac80211])
      [<c005fd10>] (process_one_work+0x1b0/0x4a8)
      [<c0060404>] (worker_thread+0x138/0x37c)
      [<c0066d70>] (kthread+0xa4/0xb0)
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4a58e7c3
    • E
      mac80211: start_next_roc only if scan was actually running · a2b70e83
      Eliad Peller 提交于
      On scan completion we try start any pending roc.
      
      However, if scan was just pending (and not actually started)
      there is no point in trying to start the roc, as it might
      have started already.
      
      This solves the following warning:
      WARNING: CPU: 0 PID: 3552 at net/mac80211/offchannel.c:269 ieee80211_start_next_roc+0x164/0x204 [mac80211]()
      [<c001cd38>] (unwind_backtrace+0x0/0xf0)
      [<c00181d0>] (show_stack+0x10/0x14)
      [<c05c0d8c>] (dump_stack+0x78/0x94)
      [<c0047c08>] (warn_slowpath_common+0x68/0x8c)
      [<c0047c48>] (warn_slowpath_null+0x1c/0x24)
      [<bf4d6660>] (ieee80211_start_next_roc+0x164/0x204 [mac80211])
      [<bf4d5a74>] (ieee80211_scan_cancel+0xe8/0x190 [mac80211])
      [<bf4df970>] (ieee80211_do_stop+0x63c/0x79c [mac80211])
      [<bf4dfae0>] (ieee80211_stop+0x10/0x18 [mac80211])
      [<c0504d84>] (__dev_close_many+0x84/0xcc)
      [<c0504df4>] (__dev_close+0x28/0x3c)
      [<c0509708>] (__dev_change_flags+0x78/0x144)
      [<c0509854>] (dev_change_flags+0x10/0x48)
      [<c055fe3c>] (devinet_ioctl+0x614/0x6d0)
      [<c04f22a0>] (sock_ioctl+0x5c/0x2a4)
      [<c0124eb4>] (do_vfs_ioctl+0x7c/0x5d8)
      [<c012547c>] (SyS_ioctl+0x6c/0x7c)
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a2b70e83
    • E
      mac80211: determine completed scan type by defined ops · 8bd2a248
      Eliad Peller 提交于
      In some cases, determining the completed scan type was
      done by testing the SCAN_HW_SCANNING flag.
      
      However, this doesn't take care for the case in which
      the hw scan was requested, but hasn't started yet (e.g.
      due to active remain_on_channel).
      
      Replace this test by checking whether ops->hw_scan is
      defined.
      
      This solves the following warning:
      
      WARNING: CPU: 0 PID: 3552 at net/mac80211/offchannel.c:156 __ieee80211_scan_completed+0x1b4/0x2dc [mac80211]()
      [<c001cd38>] (unwind_backtrace+0x0/0xf0)
      [<c00181d0>] (show_stack+0x10/0x14)
      [<c05c0d8c>] (dump_stack+0x78/0x94)
      [<c0047c08>] (warn_slowpath_common+0x68/0x8c)
      [<c0047c48>] (warn_slowpath_null+0x1c/0x24)
      [<bf4d4504>] (__ieee80211_scan_completed+0x1b4/0x2dc [mac80211])
      [<bf4d5a74>] (ieee80211_scan_cancel+0xe8/0x190 [mac80211])
      [<bf4df970>] (ieee80211_do_stop+0x63c/0x79c [mac80211])
      [<bf4dfae0>] (ieee80211_stop+0x10/0x18 [mac80211])
      [<c0504d84>] (__dev_close_many+0x84/0xcc)
      [<c0504df4>] (__dev_close+0x28/0x3c)
      [<c0509708>] (__dev_change_flags+0x78/0x144)
      [<c0509854>] (dev_change_flags+0x10/0x48)
      [<c055fe3c>] (devinet_ioctl+0x614/0x6d0)
      [<c04f22a0>] (sock_ioctl+0x5c/0x2a4)
      [<c0124eb4>] (do_vfs_ioctl+0x7c/0x5d8)
      [<c012547c>] (SyS_ioctl+0x6c/0x7c)
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      8bd2a248
    • B
      cfg80211: stop sched scan only when needed · 24d584d7
      Barak Bercovitz 提交于
      cfg80211_leave stops sched scan when any station vif
      is leaving. Add an explicit check and call it only
      when the relevant vif (the one we scan on) is leaving.
      Signed-off-by: NBarak Bercovitz <barak@wizery.com>
      [Eliad - changed the commit message a bit]
      Signed-off-by: NEliad Peller <eliad@wizery.com>
      [Johannes - add ASSERT_RTNL since that protects the pointer]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      24d584d7
  9. 05 12月, 2013 6 次提交