1. 13 Dec, 2018 1 commit
  2. 10 Nov, 2018 1 commit
    • Bob Copeland's avatar
      mac80211: fix pending queue hang due to TX_DROP · 147953b6
      Bob Copeland authored
      [ Upstream commit 6eae4a6c2be387fec41b0d2782c4fffb57159498 ]
      In our environment running lots of mesh nodes, we are seeing the
      pending queue hang periodically, with the debugfs queues file showing
      lines such as:
          00: 0x00000000/348
      i.e. there are a large number of frames but no stop reason set.
      One way this could happen is if queue processing from the pending
      tasklet exited early without processing all frames, and without having
      some future event (incoming frame, stop reason flag, ...) to reschedule
      Exactly this can occur today if ieee80211_tx() returns false due to
      packet drops or power-save buffering in the tx handlers.  In the
      past, this function would return true in such cases, and the change
      to false doesn't seem to be intentional.  Fix this case by reverting
      to the previous behavior.
      Fixes: bb42f2d1 ("mac80211: Move reorder-sensitive TX handlers to after TXQ dequeue")
      Signed-off-by: default avatarBob Copeland <bobcopeland@fb.com>
      Acked-by: default avatarToke Høiland-Jørgensen <toke@toke.dk>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
  3. 24 Mar, 2018 1 commit
    • Mohammed Shafi Shajakhan's avatar
      mac80211: Fix possible sband related NULL pointer de-reference · 92db807f
      Mohammed Shafi Shajakhan authored
      [ Upstream commit 21a8e9dd ]
      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: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 09 Dec, 2017 1 commit
    • Michal Kazior's avatar
      mac80211: prevent skb/txq mismatch · cda72bbb
      Michal Kazior authored
      [ Upstream commit dbef5362 ]
      Station structure is considered as not uploaded
      (to driver) until drv_sta_state() finishes. This
      call is however done after the structure is
      attached to mac80211 internal lists and hashes.
      This means mac80211 can lookup (and use) station
      structure before it is uploaded to a driver.
      If this happens (structure exists, but
      sta->uploaded is false) fast_tx path can still be
      taken. Deep in the fastpath call the sta->uploaded
      is checked against to derive "pubsta" argument for
      ieee80211_get_txq(). If sta->uploaded is false
      (and sta is actually non-NULL) ieee80211_get_txq()
      effectively downgraded to vif->txq.
      At first glance this may look innocent but coerces
      mac80211 into a state that is almost guaranteed
      (codel may drop offending skb) to crash because a
      station-oriented skb gets queued up on
      vif-oriented txq. The ieee80211_tx_dequeue() ends
      up looking at info->control.flags and tries to use
      txq->sta which in the fail case is NULL.
      It's probably pointless to pretend one can
      downgrade skb from sta-txq to vif-txq.
      Since downgrading unicast traffic to vif->txq must
      not be done there's no txq to put a frame on if
      sta->uploaded is false. Therefore the code is made
      to fall back to regular tx() op path if the
      described condition is hit.
      Only drivers using wake_tx_queue were affected.
      Example crash dump before fix:
       Unable to handle kernel paging request at virtual address ffffe26c
       PC is at ieee80211_tx_dequeue+0x204/0x690 [mac80211]
       [<bf4252a4>] (ieee80211_tx_dequeue [mac80211]) from
       [<bf4b1388>] (ath10k_mac_tx_push_txq+0x54/0x1c0 [ath10k_core])
       [<bf4b1388>] (ath10k_mac_tx_push_txq [ath10k_core]) from
       [<bf4bdfbc>] (ath10k_htt_txrx_compl_task+0xd78/0x11d0 [ath10k_core])
       [<bf4bdfbc>] (ath10k_htt_txrx_compl_task [ath10k_core])
       [<bf51c5a4>] (ath10k_pci_napi_poll+0x54/0xe8 [ath10k_pci])
       [<bf51c5a4>] (ath10k_pci_napi_poll [ath10k_pci]) from
       [<c0572e90>] (net_rx_action+0xac/0x160)
      Reported-by: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarSasha Levin <alexander.levin@verizon.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  5. 05 Oct, 2017 1 commit
    • Johannes Berg's avatar
      mac80211: fix VLAN handling with TXQs · 59862b04
      Johannes Berg authored
      commit 53168215 upstream.
      With TXQs, the AP_VLAN interfaces are resolved to their owner AP
      interface when enqueuing the frame, which makes sense since the
      frame really goes out on that as far as the driver is concerned.
      However, this introduces a problem: frames to be encrypted with
      a VLAN-specific GTK will now be encrypted with the AP GTK, since
      the information about which virtual interface to use to select
      the key is taken from the TXQ.
      Fix this by preserving info->control.vif and using that in the
      dequeue function. This now requires doing the driver-mapping
      in the dequeue as well.
      Since there's no way to filter the frames that are sitting on a
      TXQ, drop all frames, which may affect other interfaces, when an
      AP_VLAN is removed.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 12 Jan, 2017 1 commit
  7. 15 Nov, 2016 3 commits
  8. 30 Sep, 2016 3 commits
  9. 14 Sep, 2016 1 commit
  10. 13 Sep, 2016 2 commits
  11. 12 Sep, 2016 2 commits
  12. 11 Aug, 2016 1 commit
  13. 05 Aug, 2016 1 commit
  14. 30 Jun, 2016 2 commits
    • Michal Kazior's avatar
      mac80211: fix fq lockdep warnings · 59a7c828
      Michal Kazior authored
      Some lockdep assertions were not fulfilled and
      resulted in a kernel warning/call trace if driver
      used intermediate software queues (e.g. ath10k).
      Existing code sequences should've guaranteed safety
      but it's always good to be extra careful.
      The call trace could look like this:
       [ 237.335805] ------------[ cut here ]------------
       [ 237.335852] WARNING: CPU: 3 PID: 1921 at include/net/fq_impl.h:22 fq_flow_dequeue+0xed/0x140 [mac80211]
       [ 237.335855] Modules linked in: ath10k_pci(E-) ath10k_core(E) ath(E) mac80211(E) cfg80211(E)
       [ 237.335913] CPU: 3 PID: 1921 Comm: rmmod Tainted: G        W   E   4.7.0-rc4-wt-ath+ #1377
       [ 237.335916] Hardware name: Hewlett-Packard HP ProBook 6540b/1722, BIOS 68CDD Ver. F.04 01/27/2010
       [ 237.335918]  00200286 00200286 eff85dac c14151e2 f901574e 00000000 eff85de0 c1081075
       [ 237.335928]  c1ab91f0 00000003 00000781 f901574e 00000016 f8fbabad f8fbabad 00000016
       [ 237.335938]  eb24ff60 00000000 ef3886c0 eff85df4 c10810ba 00000009 00000000 00000000
       [ 237.335948] Call Trace:
       [ 237.335953]  [<c14151e2>] dump_stack+0x76/0xb4
       [ 237.335957]  [<c1081075>] __warn+0xe5/0x100
       [ 237.336002]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
       [ 237.336046]  [<f8fbabad>] ? fq_flow_dequeue+0xed/0x140 [mac80211]
       [ 237.336053]  [<c10810ba>] warn_slowpath_null+0x2a/0x30
       [ 237.336095]  [<f8fbabad>] fq_flow_dequeue+0xed/0x140 [mac80211]
       [ 237.336137]  [<f8fbc67a>] fq_flow_reset.constprop.56+0x2a/0x90 [mac80211]
       [ 237.336180]  [<f8fbc79a>] fq_reset.constprop.59+0x2a/0x50 [mac80211]
       [ 237.336222]  [<f8fc04e8>] ieee80211_txq_teardown_flows+0x38/0x40 [mac80211]
       [ 237.336258]  [<f8f7c1a4>] ieee80211_unregister_hw+0xe4/0x120 [mac80211]
       [ 237.336275]  [<f933f536>] ath10k_mac_unregister+0x16/0x50 [ath10k_core]
       [ 237.336292]  [<f934592d>] ath10k_core_unregister+0x3d/0x90 [ath10k_core]
       [ 237.336301]  [<f85f8836>] ath10k_pci_remove+0x36/0xa0 [ath10k_pci]
       [ 237.336307]  [<c1470388>] pci_device_remove+0x38/0xb0
      Fixes: 5caa328e ("mac80211: implement codel on fair queuing flows")
      Fixes: fa962b92 ("mac80211: implement fair queueing per txq")
      Tested-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Reported-by: default avatarKalle Valo <kvalo@qca.qualcomm.com>
      Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
    • Masashi Honma's avatar
      mac80211: Encrypt "Group addressed privacy" action frames · 46f6b060
      Masashi Honma authored
      Previously, the action frames to group address was not encrypted. But
      [1] "Table 8-38 Category values" indicates "Mesh" and "Multihop" category
      action frames should be encrypted (Group addressed privacy == yes). And the
      encyption key should be MGTK ([1] 10.13 Group addressed robust management frame
      procedures). So this patch modifies the code to make it suitable for spec.
      [1] IEEE Std 802.11-2012
      Signed-off-by: default avatarMasashi Honma <masashi.honma@gmail.com>
      Signed-off-by: default avatarJohannes Berg <johannes@sipsolutions.net>
  15. 09 Jun, 2016 3 commits
    • Michal Kazior's avatar
      mac80211: implement codel on fair queuing flows · 5caa328e
      Michal Kazior authored
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Michal Kazior's avatar
      mac80211: implement fair queueing per txq · fa962b92
      Michal Kazior authored
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Michal Kazior's avatar
      mac80211: skip netdev queue control with software queuing · 80a83cfc
      Michal Kazior authored
      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: default avatarMichal Kazior <michal.kazior@tieto.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  16. 12 Apr, 2016 1 commit
  17. 06 Apr, 2016 1 commit
    • Felix Fietkau's avatar
      mac80211: add A-MSDU tx support · 6e0456b5
      Felix Fietkau authored
      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: default avatarFelix Fietkau <nbd@openwrt.org>
      [fix locking issue]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  18. 05 Apr, 2016 7 commits
  19. 05 Mar, 2016 1 commit
  20. 24 Feb, 2016 4 commits
  21. 04 Dec, 2015 1 commit
  22. 21 Oct, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: move station statistics into sub-structs · e5a9f8d0
      Johannes Berg authored
      Group station statistics by where they're (mostly) updated
      (TX, RX and TX-status) and group them into sub-structs of
      the struct sta_info.
      Also rename the variables since the grouping now makes it
      obvious where they belong.
      This makes it easier to identify where the statistics are
      updated in the code, and thus easier to think about them.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>