All new accounts created on Gitlab now require administrator approval. If you invite any collaborators, please let Flux staff know so they can approve the accounts.

  1. 19 Dec, 2013 2 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
  2. 16 Dec, 2013 2 commits
    • Johannes Berg's avatar
      mac80211: free all AP/VLAN keys at once · 7907c7d3
      Johannes Berg authored
      When the AP interface is stopped, free all AP and VLAN keys at
      once to only require synchronize_net() once. Since that does
      synchronize_net(), also move two such calls into the function
      (using the new force_synchronize parameter) to avoid doing it
      twice.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7907c7d3
    • Johannes Berg's avatar
      mac80211: don't delay station destruction · d34ba216
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      d34ba216
  3. 03 Dec, 2013 1 commit
  4. 02 Dec, 2013 1 commit
  5. 25 Nov, 2013 3 commits
  6. 28 Oct, 2013 1 commit
    • Emmanuel Grumbach's avatar
      mac80211: implement SMPS for AP · 687da132
      Emmanuel Grumbach authored
      When the driver requests to move to STATIC or DYNAMIC SMPS,
      we send an action frame to each associated station and
      reconfigure the channel context / driver.
      Of course, non-MIMO stations are ignored.
      
      The beacon isn't updated. The association response will
      include the original capabilities. Stations that associate
      while in non-OFF SMPS mode will get an action frame right
      after association to inform them about our current state.
      Note that we wait until the end of the EAPOL. Sending an
      action frame before the EAPOL is finished can be an issue
      for a few clients. Clients aren't likely to send EAPOL
      frames in MIMO anyway.
      
      When the SMPS configuration gets more permissive (e.g.
      STATIC -> OFF), we don't wake up stations that are asleep
      We remember that they don't know about the change and send
      the action frame when they wake up.
      
      When the SMPS configuration gets more restrictive (e.g.
      OFF -> STATIC), we set the TIM bit for every sleeping STA.
      uAPSD stations might send MIMO until they poll the action
      frame, but this is for a short period of time.
      Signed-off-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      [fix vht streams loop, initialisation]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      687da132
  7. 26 Sep, 2013 1 commit
  8. 26 Aug, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: fix change_interface queue assignments · a9865538
      Johannes Berg authored
      Jouni reported that with mac80211_hwsim, multicast TX was causing
      crashes due to invalid vif->cab_queue assignment. It turns out that
      this is caused by change_interface() getting invoked and not having
      the vif->type/vif->p2p assigned correctly before calling the queue
      check (ieee80211_check_queues). Fix this by passing the 'external'
      interface type to the function and adjusting it accordingly.
      
      While at it, also fix the error path in change_interface, it wasn't
      correctly resetting to the external type but using the internal one
      instead.
      
      Fortunately this affects on hwsim because all other drivers set the
      vif->type/vif->p2p variables when changing iftype. This shouldn't
      be needed, but almost all implementations actually do it for their
      own internal handling.
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a9865538
  9. 01 Aug, 2013 1 commit
  10. 16 Jul, 2013 1 commit
  11. 29 May, 2013 1 commit
  12. 28 May, 2013 1 commit
  13. 27 May, 2013 3 commits
  14. 23 May, 2013 3 commits
    • Johannes Berg's avatar
      mac80211: close AP_VLAN interfaces before unregistering all · 4c8a9d4b
      Johannes Berg authored
      Since Eric's commit efe117ab ("Speedup ieee80211_remove_interfaces")
      there's a bug in mac80211 when it unregisters with AP_VLAN interfaces
      up. If the AP_VLAN interface was registered after the AP it belongs
      to (which is the typical case) and then we get into this code path,
      unregister_netdevice_many() will crash because it isn't prepared to
      deal with interfaces being closed in the middle of it. Exactly this
      happens though, because we iterate the list, find the AP master this
      AP_VLAN belongs to and dev_close() the dependent VLANs. After this,
      unregister_netdevice_many() won't pick up the fact that the AP_VLAN
      is already down and will do it again, causing a crash.
      
      Cc: stable@vger.kernel.org [2.6.33+]
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      4c8a9d4b
    • Johannes Berg's avatar
      mac80211: assign AP_VLAN hw queues correctly · 5f38a112
      Johannes Berg authored
      A lot of code in mac80211 assumes that the hw queues are
      set up correctly for all interfaces (except for monitor)
      but this isn't true for AP_VLAN interfaces. Fix this by
      copying the AP master configuration when an AP VLAN is
      brought up, after this the AP interface can't change its
      configuration any more and needs to be brought down to
      change it, which also forces AP_VLAN interfaces down, so
      just copying in open() is sufficient.
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      5f38a112
    • Johannes Berg's avatar
      mac80211: fix queue handling crash · 2b436312
      Johannes Berg authored
      The code I added in "mac80211: don't start new netdev queues
      if driver stopped" crashes for monitor and AP VLAN interfaces
      because while they have a netdev, they don't have queues set
      up by the driver.
      
      To fix the crash, exclude these from queue accounting here
      and just start their netdev queues unconditionally.
      
      For monitor, this is the best we can do, as we can redirect
      frames there to any other interface and don't know which one
      that will since it can be different for each frame.
      
      For AP VLAN interfaces, we can do better later and actually
      properly track the queue status. Not doing this is really a
      separate bug though.
      Reported-by: default avatarIlan Peer <ilan.peer@intel.com>
      Reported-by: default avatarJouni Malinen <j@w1.fi>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      2b436312
  15. 22 Apr, 2013 1 commit
  16. 08 Apr, 2013 8 commits
  17. 25 Mar, 2013 1 commit
  18. 20 Mar, 2013 1 commit
  19. 18 Mar, 2013 2 commits
  20. 11 Mar, 2013 1 commit
  21. 06 Mar, 2013 4 commits
    • Johannes Berg's avatar
      mac80211: simplify AP interface stop · 1861b845
      Johannes Berg authored
      For AP interfaces, there's no need to flush stations
      or keys again when the interface is stopped as already
      happened when the BSS was stopped on the interface.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      1861b845
    • Johannes Berg's avatar
      mac80211: flush keys when stopping AP · 7b4396bd
      Johannes Berg authored
      Since hostapd will remove keys this isn't usually
      an issue, but we shouldn't leak keys to the next
      BSS started on the same interface. For VLANs this
      also fixes a bug, keys that aren't removed would
      otherwise be leaked.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      7b4396bd
    • Johannes Berg's avatar
      mac80211: defer tailroom counter manipulation when roaming · 8d1f7ecd
      Johannes Berg authored
      During roaming, the crypto_tx_tailroom_needed_cnt counter
      will often take values 2,1,0,1,2 because first keys are
      removed and then new keys are added. This is inefficient
      because during the 0->1 transition, synchronize_net must
      be called to avoid packet races, although typically no
      packets would be flowing during that time.
      
      To avoid that, defer the decrement (2->1, 1->0) when keys
      are removed (by half a second). This means the counter
      will really have the values 2,2,2,3,4 ... 2, thus never
      reaching 0 and having to do the 0->1 transition.
      
      Note that this patch entirely disregards the drivers for
      which this optimisation was done to start with, for them
      the key removal itself will be expensive because it has
      to synchronize_net() after the counter is incremented to
      remove the key from HW crypto. For them the sequence will
      look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
      lot more inefficient. This could be addressed separately,
      during key removal the 0->1->0 sequence isn't necessary.
      
      (*) it starts at 0 because HW crypto is on, then goes to
          1 when HW crypto is disabled for a key, then back to
          0 because the key is deleted; this happens for both
          keys in the example. When new keys are added, it goes
          to 1 first because they're added in software; when a
          key is moved to hardware it goes back to 0
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8d1f7ecd
    • Stanislaw Gruszka's avatar
      mac80211: remove napi · 30c97120
      Stanislaw Gruszka authored
      Since two years no mac80211 driver implement support for NAPI. Looks
      this feature is unneeded, so remove it from generic mac80211 code.
      Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      30c97120