1. 19 Dec, 2013 3 commits
    • Johannes Berg's avatar
      mac80211: fix iflist_mtx/mtx locking in radar detection · 34a3740d
      Johannes Berg authored
      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: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Tested-by: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      34a3740d
    • Johannes Berg's avatar
      mac80211: remove unnecessary iflist_mtx locking · 6924d013
      Johannes Berg authored
      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: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      6924d013
    • Joe Perches's avatar
      mac80211: align struct ps_data.tim to unsigned long · 5fe2bb86
      Joe Perches authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      5fe2bb86
  2. 18 Dec, 2013 2 commits
  3. 16 Dec, 2013 16 commits
  4. 05 Dec, 2013 5 commits
    • Simon Wunderlich's avatar
      mac80211: fix nested sdata lock for IBSS/CSA · bafdc614
      Simon Wunderlich authored
      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: default avatarSimon Wunderlich <sw@simonwunderlich.de>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      bafdc614
    • Eliad Peller's avatar
      mac80211: start_next_roc only if scan was actually running · a2b70e83
      Eliad Peller authored
      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: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a2b70e83
    • Eliad Peller's avatar
      mac80211: determine completed scan type by defined ops · 8bd2a248
      Eliad Peller authored
      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: default avatarEliad Peller <eliad@wizery.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8bd2a248
    • Janusz Dziedzic's avatar
      cfg80211: in bitrate_mask, rename mcs to ht_mcs · d1e33e65
      Janusz Dziedzic authored
      Rename NL80211_TXRATE_MCS to NL80211_TXRATE_HT and also
      rename mcs to ht_mcs in struct cfg80211_bitrate_mask.
      Signed-off-by: default avatarJanusz Dziedzic <janusz.dziedzic@tieto.com>
      [reword commit message]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      d1e33e65
    • Johannes Berg's avatar
      mac80211: warn if unhashing station fails · b01711be
      Johannes Berg authored
      This shouldn't be happening, so warn if it does, since we'd
      then leak a station entry.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      b01711be
  5. 04 Dec, 2013 1 commit
  6. 03 Dec, 2013 4 commits
  7. 02 Dec, 2013 9 commits