1. 17 7月, 2015 6 次提交
  2. 10 6月, 2015 1 次提交
  3. 06 5月, 2015 1 次提交
  4. 05 5月, 2015 1 次提交
  5. 22 4月, 2015 2 次提交
    • J
      mac80211: extend fast-xmit for more ciphers · e495c247
      Johannes Berg 提交于
      When crypto is offloaded then in some cases it's all handled
      by the device, and in others only some space for the IV must
      be reserved in the frame. Handle both of these cases in the
      fast-xmit path, up to a limit of 18 bytes of space for IVs.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e495c247
    • J
      mac80211: add TX fastpath · 17c18bf8
      Johannes Berg 提交于
      In order to speed up mac80211's TX path, add the "fast-xmit" cache
      that will cache the data frame 802.11 header and other data to be
      able to build the frame more quickly. This cache is rebuilt when
      external triggers imply changes, but a lot of the checks done per
      packet today are simplified away to the check for the cache.
      
      There's also a more detailed description in the code.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      17c18bf8
  6. 20 4月, 2015 2 次提交
    • J
      mac80211: lock rate control · 35c347ac
      Johannes Berg 提交于
      Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate
      control aren't properly taking concurrency into account. It's
      likely that the same is true for other rate control algorithms.
      
      In the case of minstrel this manifests itself in crashes when an
      update and other data access are run concurrently, for example
      when the stations change bandwidth or similar. In iwlwifi, this
      can cause firmware crashes.
      
      Since fixing all rate control algorithms will be very difficult,
      just provide locking for invocations. This protects the internal
      data structures the algorithms maintain.
      
      I've manipulated hostapd to test this, by having it change its
      advertised bandwidth roughly ever 150ms. At the same time, I'm
      running a flood ping between the client and the AP, which causes
      this race of update vs. get_rate/status to easily happen on the
      client. With this change, the system survives this test.
      Reported-by: NSven Eckelmann <sven@open-mesh.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      35c347ac
    • B
      mac80211: introduce plink lock for plink fields · 48bf6bed
      Bob Copeland 提交于
      The mesh plink code uses sta->lock to serialize access to the
      plink state fields between the peer link state machine and the
      peer link timer.  Some paths (e.g. those involving
      mps_qos_null_tx()) unfortunately hold this spinlock across
      frame tx, which is soon to be disallowed.  Add a new spinlock
      just for plink access.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      48bf6bed
  7. 02 4月, 2015 1 次提交
    • F
      mac80211: add an intermediate software queue implementation · ba8c3d6f
      Felix Fietkau 提交于
      This allows drivers to request per-vif and per-sta-tid queues from which
      they can pull frames. This makes it easier to keep the hardware queues
      short, and to improve fairness between clients and vifs.
      
      The task of scheduling packet transmission is left up to the driver -
      queueing is controlled by mac80211. Drivers can only dequeue packets by
      calling ieee80211_tx_dequeue. This makes it possible to add active queue
      management later without changing drivers using this code.
      
      This can also be used as a starting point to implement A-MSDU
      aggregation in a way that does not add artificially induced latency.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      [resolved minor context conflict, minor changes, endian annotations]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ba8c3d6f
  8. 01 4月, 2015 2 次提交
    • J
      mac80211: fix RX A-MPDU session reorder timer deletion · 788211d8
      Johannes Berg 提交于
      There's an issue with the way the RX A-MPDU reorder timer is
      deleted that can cause a kernel crash like this:
      
       * tid_rx is removed - call_rcu(ieee80211_free_tid_rx)
       * station is destroyed
       * reorder timer fires before ieee80211_free_tid_rx() runs,
         accessing the station, thus potentially crashing due to
         the use-after-free
      
      The station deletion is protected by synchronize_net(), but
      that isn't enough -- ieee80211_free_tid_rx() need not have
      run when that returns (it deletes the timer.) We could use
      rcu_barrier() instead of synchronize_net(), but that's much
      more expensive.
      
      Instead, to fix this, add a field tracking that the session
      is being deleted. In this case, the only re-arming of the
      timer happens with the reorder spinlock held, so make that
      code not rearm it if the session is being deleted and also
      delete the timer after setting that field. This ensures the
      timer cannot fire after ___ieee80211_stop_rx_ba_session()
      returns, which fixes the problem.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      788211d8
    • J
      mac80211: use rhashtable for station table · 7bedd0cf
      Johannes Berg 提交于
      We currently have a hand-rolled table with 256 entries and are
      using the last byte of the MAC address as the hash. This hash
      is obviously very fast, but collisions are easily created and
      we waste a lot of space in the common case of just connecting
      as a client to an AP where we just have a single station. The
      other common case of an AP is also suboptimal due to the size
      of the hash table and the ease of causing collisions.
      
      Convert all of this to use rhashtable with jhash, which gives
      us the advantage of a far better hash function (with random
      perturbation to avoid hash collision attacks) and of course
      that the hash table grows and shrinks dynamically with chain
      length, improving both cases above.
      
      Use a specialised hash function (using jhash, but with fixed
      length) to achieve better compiler optimisation as suggested
      by Sergey Ryazanov.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7bedd0cf
  9. 01 3月, 2015 1 次提交
    • J
      mac80211: remove TX latency measurement code · abfbc3af
      Johannes Berg 提交于
      Revert commit ad38bfc9 ("mac80211: Tx frame latency statistics")
      (along with some follow-up fixes).
      
      This code turned out not to be as useful in the current form as we
      thought, and we've internally hacked it up more, but that's not
      very suitable for upstream (for now), and we might just do that
      with tracing instead.
      
      Therefore, for now at least, remove this code. We might also need
      to use the skb->tstamp field for the TCP performance issue, which
      is more important than the debugging.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      abfbc3af
  10. 08 1月, 2015 1 次提交
  11. 20 11月, 2014 3 次提交
  12. 09 10月, 2014 1 次提交
  13. 11 9月, 2014 1 次提交
  14. 05 9月, 2014 1 次提交
  15. 03 9月, 2014 1 次提交
    • M
      mac80211: fix offloaded BA session traffic after hw restart · 4549cf2b
      Michal Kazior 提交于
      When starting an offloaded BA session it is
      unknown what starting sequence number should be
      used. Using last_seq worked in most cases except
      after hw restart.
      
      When hw restart is requested last_seq is
      (rightfully so) kept unmodified. This ended up
      with BA sessions being restarted with an aribtrary
      BA window values resulting in dropped frames until
      sequence numbers caught up.
      
      Instead of last_seq pick seqno of a first Rxed
      frame of a given BA session.
      
      This fixes stalled traffic after hw restart with
      offloaded BA sessions (currently only ath10k).
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      4549cf2b
  16. 15 8月, 2014 1 次提交
  17. 21 7月, 2014 2 次提交
  18. 23 6月, 2014 4 次提交
    • J
      cfg80211: make ethtool the driver's responsibility · b7ffbd7e
      Johannes Berg 提交于
      Currently, cfg80211 tries to implement ethtool, but that doesn't
      really scale well, with all the different operations. Make the
      lower-level driver responsible for it, which currently only has
      an effect on mac80211. It will similarly not scale well at that
      level though, since mac80211 also has many drivers.
      
      To cleanly implement this in mac80211, introduce a new file and
      move some code to appropriate places.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      b7ffbd7e
    • J
      mac80211: remove weak WEP IV accounting · ba9030c2
      Johannes Berg 提交于
      Since WEP is practically dead, there seems very little
      point in keeping WEP weak IV accounting.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      ba9030c2
    • B
      mac80211: remove ignore_plink_timer flag · 2b470c39
      Bob Copeland 提交于
      The mesh_plink code is doing some interesting things with the
      ignore_plink_timer flag.  It seems the original intent was to
      handle this race:
      
      cpu 0                           cpu 1
      -----                           -----
                                      start timer handler for state X
      acquire sta_lock
      change state from X to Y
      mod_timer() / del_timer()
      release sta_lock
                                      acquire sta_lock
                                      execute state Y timer too soon
      
      However, using the mod_timer()/del_timer() return values to
      detect these cases is broken.  As a result, timers get ignored
      unnecessarily, and stations can get stuck in the peering state
      machine.
      
      Instead, we can detect the case by looking at the timer expiration.
      In the case of del_timer, just ignore the timers in the following
      (LISTEN/ESTAB) states since they won't have timers anyway.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      2b470c39
    • J
      mac80211: fix station/driver powersave race · 5ac2e350
      Johannes Berg 提交于
      It is currently possible to have a race due to the station PS
      unblock work like this:
       * station goes to sleep with frames buffered in the driver
       * driver blocks wakeup
       * station wakes up again
       * driver flushes/returns frames, and unblocks, which schedules
         the unblock work
       * unblock work starts to run, and checks that the station is
         awake (i.e. that the WLAN_STA_PS_STA flag isn't set)
       * we process a received frame with PM=1, setting the flag again
       * ieee80211_sta_ps_deliver_wakeup() runs, delivering all frames
         to the driver, and then clearing the WLAN_STA_PS_DRIVER and
         WLAN_STA_PS_STA flags
      
      In this scenario, mac80211 will think that the station is awake,
      while it really is asleep, and any TX'ed frames should be filtered
      by the device (it will know that the station is sleeping) but then
      passed to mac80211 again, which will not buffer it either as it
      thinks the station is awake, and eventually the packets will be
      dropped.
      
      Fix this by moving the clearing of the flags to exactly where we
      learn about the situation. This creates a problem of reordering,
      so introduce another flag indicating that delivery is being done,
      this new flag also queues frames and is cleared only while the
      spinlock is held (which the queuing code also holds) so that any
      concurrent delivery/TX is handled correctly.
      Reported-by: NAndrei Otcheretianski <andrei.otcheretianski@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5ac2e350
  19. 20 2月, 2014 1 次提交
    • E
      mac80211: fix AP powersave TX vs. wakeup race · 1d147bfa
      Emmanuel Grumbach 提交于
      There is a race between the TX path and the STA wakeup: while
      a station is sleeping, mac80211 buffers frames until it wakes
      up, then the frames are transmitted. However, the RX and TX
      path are concurrent, so the packet indicating wakeup can be
      processed while a packet is being transmitted.
      
      This can lead to a situation where the buffered frames list
      is emptied on the one side, while a frame is being added on
      the other side, as the station is still seen as sleeping in
      the TX path.
      
      As a result, the newly added frame will not be send anytime
      soon. It might be sent much later (and out of order) when the
      station goes to sleep and wakes up the next time.
      
      Additionally, it can lead to the crash below.
      
      Fix all this by synchronising both paths with a new lock.
      Both path are not fastpath since they handle PS situations.
      
      In a later patch we'll remove the extra skb queue locks to
      reduce locking overhead.
      
      BUG: unable to handle kernel
      NULL pointer dereference at 000000b0
      IP: [<ff6f1791>] ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
      *pde = 00000000
      Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
      EIP: 0060:[<ff6f1791>] EFLAGS: 00210282 CPU: 1
      EIP is at ieee80211_report_used_skb+0x11/0x3e0 [mac80211]
      EAX: e5900da0 EBX: 00000000 ECX: 00000001 EDX: 00000000
      ESI: e41d00c0 EDI: e5900da0 EBP: ebe458e4 ESP: ebe458b0
       DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
      CR0: 8005003b CR2: 000000b0 CR3: 25a78000 CR4: 000407d0
      DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000
      DR6: ffff0ff0 DR7: 00000400
      Process iperf (pid: 3934, ti=ebe44000 task=e757c0b0 task.ti=ebe44000)
      iwlwifi 0000:02:00.0: I iwl_pcie_enqueue_hcmd Sending command LQ_CMD (#4e), seq: 0x0903, 92 bytes at 3[3]:9
      Stack:
       e403b32c ebe458c4 00200002 00200286 e403b338 ebe458cc c10960bb e5900da0
       ff76a6ec ebe458d8 00000000 e41d00c0 e5900da0 ebe458f0 ff6f1b75 e403b210
       ebe4598c ff723dc1 00000000 ff76a6ec e597c978 e403b758 00000002 00000002
      Call Trace:
       [<ff6f1b75>] ieee80211_free_txskb+0x15/0x20 [mac80211]
       [<ff723dc1>] invoke_tx_handlers+0x1661/0x1780 [mac80211]
       [<ff7248a5>] ieee80211_tx+0x75/0x100 [mac80211]
       [<ff7249bf>] ieee80211_xmit+0x8f/0xc0 [mac80211]
       [<ff72550e>] ieee80211_subif_start_xmit+0x4fe/0xe20 [mac80211]
       [<c149ef70>] dev_hard_start_xmit+0x450/0x950
       [<c14b9aa9>] sch_direct_xmit+0xa9/0x250
       [<c14b9c9b>] __qdisc_run+0x4b/0x150
       [<c149f732>] dev_queue_xmit+0x2c2/0xca0
      
      Cc: stable@vger.kernel.org
      Reported-by: NYaara Rozenblum <yaara.rozenblum@intel.com>
      Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
      Reviewed-by: NStanislaw Gruszka <sgruszka@redhat.com>
      [reword commit log, use a separate lock]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      1d147bfa
  20. 06 2月, 2014 1 次提交
  21. 16 12月, 2013 3 次提交
  22. 02 12月, 2013 1 次提交
  23. 26 11月, 2013 2 次提交