1. 06 9月, 2017 1 次提交
    • J
      mac80211: fix deadlock in driver-managed RX BA session start · bde59c47
      Johannes Berg 提交于
      When an RX BA session is started by the driver, and it has to tell
      mac80211 about it, the corresponding bit in tid_rx_manage_offl gets
      set and the BA session work is scheduled. Upon testing this bit, it
      will call __ieee80211_start_rx_ba_session(), thus deadlocking as it
      already holds the ampdu_mlme.mtx, which that acquires again.
      
      Fix this by adding ___ieee80211_start_rx_ba_session(), a version of
      the function that requires the mutex already held.
      
      Cc: stable@vger.kernel.org
      Fixes: 699cb58c ("mac80211: manage RX BA session offload without SKB queue")
      Reported-by: NMatteo Croce <mcroce@redhat.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      bde59c47
  2. 13 6月, 2017 1 次提交
  3. 08 6月, 2017 1 次提交
    • J
      mac80211: manage RX BA session offload without SKB queue · 699cb58c
      Johannes Berg 提交于
      Instead of using the SKB queue with the fake pkt_type for the
      offloaded RX BA session management, also handle this with the
      normal aggregation state machine worker. This also makes the
      use of this more reliable since it gets rid of the allocation
      of the fake skb.
      
      Combined with the previous patch, this finally allows us to
      get rid of the pkt_type hack entirely, so do that as well.
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      699cb58c
  4. 30 5月, 2017 1 次提交
    • J
      mac80211: fix TX aggregation start/stop callback race · 7a7c0a64
      Johannes Berg 提交于
      When starting or stopping an aggregation session, one of the steps
      is that the driver calls back to mac80211 that the start/stop can
      proceed. This is handled by queueing up a fake SKB and processing
      it from the normal iface/sdata work. Since this isn't flushed when
      disassociating, the following race is possible:
      
       * associate
       * start aggregation session
       * driver callback
       * disassociate
       * associate again to the same AP
       * callback processing runs, leading to a WARN_ON() that
         the TID hadn't requested aggregation
      
      If the second association isn't to the same AP, there would only
      be a message printed ("Could not find station: <addr>"), but the
      same race could happen.
      
      Fix this by not going the whole detour with a fake SKB etc. but
      simply looking up the aggregation session in the driver callback,
      marking it with a START_CB/STOP_CB bit and then scheduling the
      regular aggregation work that will now process these bits as well.
      This also simplifies the code and gets rid of the whole problem
      with allocation failures of said skb, which could have left the
      session in limbo.
      Reported-by: NJouni Malinen <j@w1.fi>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7a7c0a64
  5. 24 5月, 2017 1 次提交
  6. 19 5月, 2017 2 次提交
  7. 28 4月, 2017 4 次提交
    • A
      mac80211: Add support for BSS max idle period element · e38a017b
      Avraham Stern 提交于
      Parse the BSS max idle period element and set the BSS configuration
      accordingly so the driver can use this information to configure the
      max idle period and to use protected management frames for keep alive
      when required.
      
      The BSS max idle period element is defined in IEEE802.11-2016,
      section 9.4.2.79
      Signed-off-by: NAvraham Stern <avraham.stern@intel.com>
      Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      e38a017b
    • M
      mac80211: Fix possible sband related NULL pointer de-reference · 21a8e9dd
      Mohammed Shafi Shajakhan 提交于
      Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even
      if the channel context configuration is NULL. This crashes for chipsets
      which support 5 Ghz alone when it tries to access members of 'sband'.
      Channel context configuration can be NULL in multivif case and when
      channel switch is in progress (or) when it fails. Fix this by replacing
      the API 'ieee80211_get_sdata_band' with  'ieee80211_get_sband' which
      returns a NULL pointer for sband when the channel configuration is NULL.
      
      An example scenario is as below:
      
      In multivif mode (AP + STA) with drivers like ath10k, when we do a
      channel switch in the AP vif (which has a number of clients connected)
      and a STA vif which is connected to some other AP, when the channel
      switch in AP vif fails, while the STA vifs tries to connect to the
      other AP, there is a window where the channel context is NULL/invalid
      and this results in a crash  while the clients connected to the AP vif
      tries to reconnect and this race is very similar to the one investigated
      by Michal in https://patchwork.kernel.org/patch/3788161/ and this does
      happens with hardware that supports 5Ghz alone after long hours of
      testing with continuous channel switch on the AP vif
      
      ieee80211 phy0: channel context reservation cannot be finalized because
      some interfaces aren't switching
      wlan0: failed to finalize CSA, disconnecting
      wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice
      	(Reason: 3=DEAUTH_LEAVING)
      
      	WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211]
      	[<bf77272c>] (sta_info_alloc [mac80211])
      	[<bf78776c>] (ieee80211_add_station [mac80211]))
      	[<bf73cc50>] (nl80211_new_station [cfg80211])
      
      	Unable to handle kernel NULL pointer dereference at virtual
      	address 00000014
      	pgd = d5f4c000
      	Internal error: Oops: 17 [#1] PREEMPT SMP ARM
      	PC is at sta_info_alloc+0x380/0x3fc [mac80211]
      	LR is at sta_info_alloc+0x37c/0x3fc [mac80211]
      	[<bf772738>] (sta_info_alloc [mac80211])
      	[<bf78776c>] (ieee80211_add_station [mac80211])
      	[<bf73cc50>] (nl80211_new_station [cfg80211]))
      
      Cc: Michal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      21a8e9dd
    • J
      mac80211: separate encoding/bandwidth from flags · da6a4352
      Johannes Berg 提交于
      We currently use a lot of flags that are mutually incompatible,
      separate this out into actual encoding and bandwidth enum values.
      
      Much of this again done with spatch, with manual post-editing,
      mostly to add the switch statements and get rid of the conversions.
      
      @@
      expression status;
      @@
      -status->enc_flags |= RX_ENC_FLAG_80MHZ
      +status->bw = RATE_INFO_BW_80
      @@
      expression status;
      @@
      -status->enc_flags |= RX_ENC_FLAG_40MHZ
      +status->bw = RATE_INFO_BW_40
      @@
      expression status;
      @@
      -status->enc_flags |= RX_ENC_FLAG_20MHZ
      +status->bw = RATE_INFO_BW_20
      @@
      expression status;
      @@
      -status->enc_flags |= RX_ENC_FLAG_160MHZ
      +status->bw = RATE_INFO_BW_160
      @@
      expression status;
      @@
      -status->enc_flags |= RX_ENC_FLAG_5MHZ
      +status->bw = RATE_INFO_BW_5
      @@
      expression status;
      @@
      -status->enc_flags |= RX_ENC_FLAG_10MHZ
      +status->bw = RATE_INFO_BW_10
      
      @@
      expression status;
      @@
      -status->enc_flags |= RX_ENC_FLAG_VHT
      +status->encoding = RX_ENC_VHT
      @@
      expression status;
      @@
      -status->enc_flags |= RX_ENC_FLAG_HT
      +status->encoding = RX_ENC_HT
      @@
      expression status;
      @@
      -status.enc_flags |= RX_ENC_FLAG_VHT
      +status.encoding = RX_ENC_VHT
      @@
      expression status;
      @@
      -status.enc_flags |= RX_ENC_FLAG_HT
      +status.encoding = RX_ENC_HT
      
      @@
      expression status;
      @@
      -(status->enc_flags & RX_ENC_FLAG_HT)
      +(status->encoding == RX_ENC_HT)
      @@
      expression status;
      @@
      -(status->enc_flags & RX_ENC_FLAG_VHT)
      +(status->encoding == RX_ENC_VHT)
      
      @@
      expression status;
      @@
      -(status->enc_flags & RX_ENC_FLAG_5MHZ)
      +(status->bw == RATE_INFO_BW_5)
      @@
      expression status;
      @@
      -(status->enc_flags & RX_ENC_FLAG_10MHZ)
      +(status->bw == RATE_INFO_BW_10)
      @@
      expression status;
      @@
      -(status->enc_flags & RX_ENC_FLAG_40MHZ)
      +(status->bw == RATE_INFO_BW_40)
      @@
      expression status;
      @@
      -(status->enc_flags & RX_ENC_FLAG_80MHZ)
      +(status->bw == RATE_INFO_BW_80)
      @@
      expression status;
      @@
      -(status->enc_flags & RX_ENC_FLAG_160MHZ)
      +(status->bw == RATE_INFO_BW_160)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      da6a4352
    • J
      mac80211: clean up rate encoding bits in RX status · 7fdd69c5
      Johannes Berg 提交于
      In preparation for adding support for HE rates, clean up
      the driver report encoding for rate/bandwidth reporting
      on RX frames.
      
      Much of this patch was done with the following spatch:
      
      @@
      expression status;
      @@
      -status->flag & (RX_FLAG_HT | RX_FLAG_VHT)
      +status->enc_flags & (RX_ENC_FLAG_HT | RX_ENC_FLAG_VHT)
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_SHORTPRE
      +status->enc_flags op RX_ENC_FLAG_SHORTPRE
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_SHORTPRE
      +status->enc_flags & RX_ENC_FLAG_SHORTPRE
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_HT
      +status->enc_flags op RX_ENC_FLAG_HT
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_HT
      +status->enc_flags & RX_ENC_FLAG_HT
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_40MHZ
      +status->enc_flags op RX_ENC_FLAG_40MHZ
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_40MHZ
      +status->enc_flags & RX_ENC_FLAG_40MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_SHORT_GI
      +status->enc_flags op RX_ENC_FLAG_SHORT_GI
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_SHORT_GI
      +status->enc_flags & RX_ENC_FLAG_SHORT_GI
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_HT_GF
      +status->enc_flags op RX_ENC_FLAG_HT_GF
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_HT_GF
      +status->enc_flags & RX_ENC_FLAG_HT_GF
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_VHT
      +status->enc_flags op RX_ENC_FLAG_VHT
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_VHT
      +status->enc_flags & RX_ENC_FLAG_VHT
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_STBC_MASK
      +status->enc_flags op RX_ENC_FLAG_STBC_MASK
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_STBC_MASK
      +status->enc_flags & RX_ENC_FLAG_STBC_MASK
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_LDPC
      +status->enc_flags op RX_ENC_FLAG_LDPC
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_LDPC
      +status->enc_flags & RX_ENC_FLAG_LDPC
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_10MHZ
      +status->enc_flags op RX_ENC_FLAG_10MHZ
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_10MHZ
      +status->enc_flags & RX_ENC_FLAG_10MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->flag op RX_FLAG_5MHZ
      +status->enc_flags op RX_ENC_FLAG_5MHZ
      @@
      expression status;
      @@
      -status->flag & RX_FLAG_5MHZ
      +status->enc_flags & RX_ENC_FLAG_5MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->vht_flag op RX_VHT_FLAG_80MHZ
      +status->enc_flags op RX_ENC_FLAG_80MHZ
      @@
      expression status;
      @@
      -status->vht_flag & RX_VHT_FLAG_80MHZ
      +status->enc_flags & RX_ENC_FLAG_80MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->vht_flag op RX_VHT_FLAG_160MHZ
      +status->enc_flags op RX_ENC_FLAG_160MHZ
      @@
      expression status;
      @@
      -status->vht_flag & RX_VHT_FLAG_160MHZ
      +status->enc_flags & RX_ENC_FLAG_160MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status->vht_flag op RX_VHT_FLAG_BF
      +status->enc_flags op RX_ENC_FLAG_BF
      @@
      expression status;
      @@
      -status->vht_flag & RX_VHT_FLAG_BF
      +status->enc_flags & RX_ENC_FLAG_BF
      
      @@
      assignment operator op;
      expression status, STBC;
      @@
      -status->flag op STBC << RX_FLAG_STBC_SHIFT
      +status->enc_flags op STBC << RX_ENC_FLAG_STBC_SHIFT
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_SHORTPRE
      +status.enc_flags op RX_ENC_FLAG_SHORTPRE
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_SHORTPRE
      +status.enc_flags & RX_ENC_FLAG_SHORTPRE
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_HT
      +status.enc_flags op RX_ENC_FLAG_HT
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_HT
      +status.enc_flags & RX_ENC_FLAG_HT
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_40MHZ
      +status.enc_flags op RX_ENC_FLAG_40MHZ
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_40MHZ
      +status.enc_flags & RX_ENC_FLAG_40MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_SHORT_GI
      +status.enc_flags op RX_ENC_FLAG_SHORT_GI
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_SHORT_GI
      +status.enc_flags & RX_ENC_FLAG_SHORT_GI
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_HT_GF
      +status.enc_flags op RX_ENC_FLAG_HT_GF
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_HT_GF
      +status.enc_flags & RX_ENC_FLAG_HT_GF
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_VHT
      +status.enc_flags op RX_ENC_FLAG_VHT
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_VHT
      +status.enc_flags & RX_ENC_FLAG_VHT
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_STBC_MASK
      +status.enc_flags op RX_ENC_FLAG_STBC_MASK
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_STBC_MASK
      +status.enc_flags & RX_ENC_FLAG_STBC_MASK
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_LDPC
      +status.enc_flags op RX_ENC_FLAG_LDPC
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_LDPC
      +status.enc_flags & RX_ENC_FLAG_LDPC
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_10MHZ
      +status.enc_flags op RX_ENC_FLAG_10MHZ
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_10MHZ
      +status.enc_flags & RX_ENC_FLAG_10MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.flag op RX_FLAG_5MHZ
      +status.enc_flags op RX_ENC_FLAG_5MHZ
      @@
      expression status;
      @@
      -status.flag & RX_FLAG_5MHZ
      +status.enc_flags & RX_ENC_FLAG_5MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.vht_flag op RX_VHT_FLAG_80MHZ
      +status.enc_flags op RX_ENC_FLAG_80MHZ
      @@
      expression status;
      @@
      -status.vht_flag & RX_VHT_FLAG_80MHZ
      +status.enc_flags & RX_ENC_FLAG_80MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.vht_flag op RX_VHT_FLAG_160MHZ
      +status.enc_flags op RX_ENC_FLAG_160MHZ
      @@
      expression status;
      @@
      -status.vht_flag & RX_VHT_FLAG_160MHZ
      +status.enc_flags & RX_ENC_FLAG_160MHZ
      
      @@
      assignment operator op;
      expression status;
      @@
      -status.vht_flag op RX_VHT_FLAG_BF
      +status.enc_flags op RX_ENC_FLAG_BF
      @@
      expression status;
      @@
      -status.vht_flag & RX_VHT_FLAG_BF
      +status.enc_flags & RX_ENC_FLAG_BF
      
      @@
      assignment operator op;
      expression status, STBC;
      @@
      -status.flag op STBC << RX_FLAG_STBC_SHIFT
      +status.enc_flags op STBC << RX_ENC_FLAG_STBC_SHIFT
      
      @@
      @@
      -RX_FLAG_STBC_SHIFT
      +RX_ENC_FLAG_STBC_SHIFT
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      7fdd69c5
  8. 18 4月, 2017 1 次提交
  9. 02 3月, 2017 1 次提交
  10. 16 12月, 2016 1 次提交
  11. 13 12月, 2016 3 次提交
  12. 27 10月, 2016 1 次提交
  13. 19 10月, 2016 1 次提交
  14. 17 10月, 2016 1 次提交
  15. 12 10月, 2016 1 次提交
    • M
      mac80211: filter multicast data packets on AP / AP_VLAN · 72f15d53
      Michael Braun 提交于
      This patch adds filtering for multicast data packets on AP_VLAN
      interfaces that have no authorized station connected and changes
      filtering on AP interfaces to not count stations assigned to
      AP_VLAN interfaces.
      
      This saves airtime and avoids waking up other stations currently
      authorized in this BSS. When using WPA, the packets dropped could
      not be decrypted by any station.
      
      The behaviour when there are no AP_VLAN interfaces is left unchanged.
      
      When there are AP_VLAN interfaces, this patch
      1. adds filtering multicast data packets sent on AP_VLAN interfaces
         that have no authorized station connected.
         No filtering happens on 4addr AP_VLAN interfaces.
      2. makes filtering of multicast data packets sent on AP interfaces
         depend on the number of authorized stations in this bss not
         assigned to an AP_VLAN interface.
      
      Therefore, a new num_mcast_sta counter is added for AP_VLAN interfaces.
      The existing one for AP interfaces is altered to not track stations
      assigned to an AP_VLAN interface.
      
      The new counter is exposed in debugfs.
      Signed-off-by: NMichael Braun <michael-dev@fami-braun.de>
      [reformat commit message a bit, unline ieee80211_vif_{inc,dec}_num_mcast]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      72f15d53
  16. 30 9月, 2016 3 次提交
  17. 20 9月, 2016 1 次提交
    • H
      mac80211: Use rhltable instead of rhashtable · 83e7e4ce
      Herbert Xu 提交于
      mac80211 currently uses rhashtable with insecure_elasticity set
      to true.  The latter is because of duplicate objects.  What's
      more, mac80211 walks the rhashtable chains by hand which is broken
      as rhashtable may contain multiple tables due to resizing or
      rehashing.
      
      This patch fixes it by converting it to the newly added rhltable
      interface which is designed for use with duplicate objects.
      
      With rhltable a lookup returns a list of objects instead of a
      single one.  This is then fed into the existing for_each_sta_info
      macro.
      
      This patch also deletes the sta_addr_hash function since rhashtable
      defaults to jhash.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      83e7e4ce
  18. 13 9月, 2016 1 次提交
  19. 12 9月, 2016 2 次提交
  20. 06 7月, 2016 1 次提交
  21. 09 6月, 2016 3 次提交
    • M
      mac80211: implement codel on fair queuing flows · 5caa328e
      Michal Kazior 提交于
      There is no other limit other than a global
      packet count limit when using software queuing.
      This means a single flow queue can grow insanely
      long. This is particularly bad for TCP congestion
      algorithms which requires a little more
      sophisticated frame dropping scheme than a mere
      headdrop on limit overflow.
      
      Hence apply (a slighly modified, to fit the knobs)
      CoDel5 on flow queues. This improves TCP
      convergence and stability when combined with
      wireless driver which keeps its own tx queue/fifo
      at a minimum fill level for given link conditions.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      5caa328e
    • M
      mac80211: implement fair queueing per txq · fa962b92
      Michal Kazior 提交于
      mac80211's software queues were designed to work
      very closely with device tx queues. They are
      required to make use of 802.11 packet aggregation
      easily and efficiently.
      
      Due to the way 802.11 aggregation is designed it
      only makes sense to keep fair queuing as close to
      hardware as possible to reduce induced latency and
      inertia and provide the best flow responsiveness.
      
      This change doesn't translate directly to
      immediate and significant gains. End result
      depends on driver's induced latency. Best results
      can be achieved if driver keeps its own tx
      queue/fifo fill level to a minimum.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      fa962b92
    • M
      mac80211: skip netdev queue control with software queuing · 80a83cfc
      Michal Kazior 提交于
      Qdiscs are designed with no regard to 802.11
      aggregation requirements and hand out
      packet-by-packet with no guarantee they are
      destined to the same tid. This does more bad than
      good no matter how fairly a given qdisc may behave
      on an ethernet interface.
      
      Software queuing used per-AC netdev subqueue
      congestion control whenever a global AC limit was
      hit. This meant in practice a single station or
      tid queue could starve others rather easily. This
      could resonate with qdiscs in a bad way or could
      just end up with poor aggregation performance.
      Increasing the AC limit would increase induced
      latency which is also bad.
      
      Disabling qdiscs by default and performing
      taildrop instead of netdev subqueue congestion
      control on the other hand makes it possible for
      tid queues to fill up "in the meantime" while
      preventing stations starving each other.
      
      This increases aggregation opportunities and
      should allow software queuing based drivers
      achieve better performance by utilizing airtime
      more efficiently with big aggregates.
      Signed-off-by: NMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      80a83cfc
  22. 12 4月, 2016 1 次提交
  23. 06 4月, 2016 2 次提交
    • F
      mac80211: add A-MSDU tx support · 6e0456b5
      Felix Fietkau 提交于
      Requires software tx queueing and fast-xmit support. For good
      performance, drivers need frag_list support as well. This avoids the
      need for copying data of aggregated frames. Running without it is only
      supported for debugging purposes.
      
      To avoid performance and packet size issues, the rate control module or
      driver needs to limit the maximum A-MSDU size by setting
      max_rc_amsdu_len in struct ieee80211_sta.
      Signed-off-by: NFelix Fietkau <nbd@openwrt.org>
      [fix locking issue]
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      6e0456b5
    • J
      mac80211: add fast-rx path · 49ddf8e6
      Johannes Berg 提交于
      The regular RX path has a lot of code, but with a few
      assumptions on the hardware it's possible to reduce the
      amount of code significantly. Currently the assumptions
      on the driver are the following:
       * hardware/driver reordering buffer (if supporting aggregation)
       * hardware/driver decryption & PN checking (if using encryption)
       * hardware/driver did de-duplication
       * hardware/driver did A-MSDU deaggregation
       * AP_LINK_PS is used (in AP mode)
       * no client powersave handling in mac80211 (in client mode)
      
      of which some are actually checked per packet:
       * de-duplication
       * PN checking
       * decryption
      and additionally packets must
       * not be A-MSDU (have been deaggregated by driver/device)
       * be data packets
       * not be fragmented
       * be unicast
       * have RFC 1042 header
      
      Additionally dynamically we assume:
       * no encryption or CCMP/GCMP, TKIP/WEP/other not allowed
       * station must be authorized
       * 4-addr format not enabled
      
      Some data needed for the RX path is cached in a new per-station
      "fast_rx" structure, so that we only need to look at this and
      the packet, no other memory when processing packets on the fast
      RX path.
      
      After doing the above per-packet checks, the data path collapses
      down to a pretty simple conversion function taking advantage of
      the data cached in the small fast_rx struct.
      
      This should speed up the RX processing, and will make it easier
      to reason about parallelizing RX (for which statistics will need
      to be per-CPU still.)
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      49ddf8e6
  24. 05 4月, 2016 3 次提交
  25. 01 3月, 2016 1 次提交
    • J
      mac80211: check PN correctly for GCMP-encrypted fragmented MPDUs · 9acc54be
      Johannes Berg 提交于
      Just like for CCMP we need to check that for GCMP the fragments
      have PNs that increment by one; the spec was updated to fix this
      security issue and now has the following text:
      
      	The receiver shall discard MSDUs and MMPDUs whose constituent
      	MPDU PN values are not incrementing in steps of 1.
      
      Adapt the code for CCMP to work for GCMP as well, luckily the
      relevant fields already alias each other so no code duplication
      is needed (just check the aliasing with BUILD_BUG_ON.)
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      9acc54be
  26. 24 2月, 2016 1 次提交