1. 16 12月, 2013 5 次提交
    • J
      mac80211: optimise synchronize_net() for sta_info_flush · d778207b
      Johannes Berg 提交于
      There's no reason to have one synchronize_net() for each
      removed station, refactor the code slightly to have just
      a single synchronize_net() for all stations.
      
      Note that this is currently useless as hostapd removes
      stations one by one and this coalescing never happens.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d778207b
    • J
      mac80211: move synchronize_net() before sta key removal · c8782078
      Johannes Berg 提交于
      There's no reason to do this inside the sta key removal
      since the keys can only be reached through the sta (and
      not by the driver at all) so once the sta can no longer
      be reached, the keys are safe.
      
      This will allow further optimisation opportunities with
      multiple stations.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      c8782078
    • J
      mac80211: don't delay station destruction · d34ba216
      Johannes Berg 提交于
      If we can assume that stations are never referenced by the
      driver after sta_state returns (and this is true since the
      previous iwlmvm patch and for all other drivers) then we
      don't need to delay station destruction, and don't need to
      play tricks with rcu_barrier() etc.
      
      This should speed up some scenarios like hostapd shutdown.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d34ba216
    • J
      mac80211: move 4-addr sta pointer clearing before synchronize_rcu() · a710c816
      Johannes Berg 提交于
      The pointer should be cleared before synchronize_rcu() so that the
      consequently dead station won't be found by any lookups in the TX
      or RX paths.
      
      Also check that the station is actually the one being removed, the
      check is not needed because each 4-addr VLAN can only have a single
      station and non-4-addr VLANs always have a NULL pointer there, but
      the code is clearer this way (and we avoid the memory write.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      a710c816
    • J
      mac80211: add pre-RCU-sync sta removal driver operation · 6a9d1b91
      Johannes Berg 提交于
      Currently, mac80211 allows drivers to keep RCU-protected station
      references that are cleared when the station is removed from the
      driver and consequently needs to synchronize twice, once before
      removing the station from the driver (so it can guarantee that
      the station is no longer used in TX towards the driver) and once
      after the station is removed from the driver.
      
      Add a new pre-RCU-synchronisation station removal operation to
      the API to allow drivers to clear/invalidate their RCU-protected
      station pointers before the RCU synchronisation.
      
      This will allow removing the second synchronisation by changing
      the driver API so that the driver may no longer assume a valid
      RCU-protected pointer after sta_remove/sta_state returns.
      
      The alternative to this would be to synchronize_rcu() in all the
      drivers that currently rely on this behaviour (only iwlmvm) but
      that would defeat the purpose.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6a9d1b91
  2. 06 12月, 2013 3 次提交
    • 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
      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
  3. 05 12月, 2013 2 次提交
  4. 04 12月, 2013 1 次提交
  5. 03 12月, 2013 4 次提交
  6. 02 12月, 2013 11 次提交
  7. 26 11月, 2013 14 次提交