1. 02 Dec, 2020 2 commits
    • Sven Eckelmann's avatar
      ath11k: Reset ath11k_skb_cb before setting new flags · 5da7acfe
      Sven Eckelmann authored
      It was observed that the codepath for the ATH11K_SKB_HW_80211_ENCAP was
      used even when the IEEE80211_TX_CTRL_HW_80211_ENCAP was not enabled for a
      an skbuff. This became even more prominent when the QCAs wlan-open patchset
      for ath11k [1] was applied and a sane looking fix just caused crashes when
      injecting frames via a monitor interface (for example with ratechecker):
      
        [   86.963152] Unable to handle kernel NULL pointer dereference at virtual address 00000338
        [   86.963192] pgd = ffffffc0008f0000
        [   86.971034] [00000338] *pgd=0000000051706003, *pud=0000000051706003, *pmd=0000000051707003, *pte=00e800000b000707
        [   86.984292] Internal error: Oops: 96000006 [#1] PREEMPT SMP
        [...]
        [   87.713339] [<ffffffbffc802480>] ieee80211_tx_status_8023+0xf8/0x220 [mac80211]
        [   87.715654] [<ffffffbffc98bad4>] ath11k_dp_tx_completion_handler+0x42c/0xa10 [ath11k]
        [   87.722924] [<ffffffbffc989190>] ath11k_dp_service_srng+0x70/0x3c8 [ath11k]
        [   87.730831] [<ffffffbffca03460>] 0xffffffbffca03460
        [   87.737599] [<ffffffc00046ef58>] net_rx_action+0xf8/0x288
        [   87.742462] [<ffffffc000097554>] __do_softirq+0xfc/0x220
        [   87.748014] [<ffffffc000097900>] irq_exit+0x98/0xe8
        [   87.753396] [<ffffffc0000cf188>] __handle_domain_irq+0x90/0xb8
        [   87.757999] [<ffffffc000081ca4>] gic_handle_irq+0x6c/0xc8
        [   87.763899] Exception stack(0xffffffc00081bdc0 to 0xffffffc00081bef0)
      
      Problem is that the state of ath11k_skb_cb->flags must be considered
      unknown and could contain anything when it is not manually initialized. So
      it could also contain ATH11K_SKB_HW_80211_ENCAP. And this can result in the
      code to assume that the ath11k_skb_cb->vif is set - even when this is not
      always the case for non ATH11K_SKB_HW_80211_ENCAP transmissions.
      
      Tested-on: IPQ8074 hw2.0 WLAN.HK.2.4.0.1.r1-00026-QCAHKSWPL_SILICONZ-2
      
      [1] https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches?h=NHSS.QSDK.11.4.r3
          (162 patches at the moment which are often not upstreamed but essential
           to get ath11k working)
      
      Fixes: e7f33e0c ("ath11k: add tx hw 802.11 encapsulation offloading support")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20201119154235.263250-2-sven@narfation.org
      5da7acfe
    • Sven Eckelmann's avatar
      ath11k: Don't cast ath11k_skb_cb to ieee80211_tx_info.control · f4d291b4
      Sven Eckelmann authored
      The driver_data area of ieee80211_tx_info is used in ath11k for
      ath11k_skb_cb. The first function in the TX patch which rewrites it to
      ath11k_skb_cb is already ath11k_mac_op_tx. No one else in the code path
      must use it for something else before it reinitializes it. Otherwise the
      data has to be considered uninitialized or corrupt.
      
      But the ieee80211_tx_info.control shares exactly the same area as
      ieee80211_tx_info.driver_data and ath11k is still using it. This results in
      best case in a
      
        ath11k c000000.wifi1: no vif found for mgmt frame, flags 0x0
      
      or (slightly worse) in a kernel oops.
      
      Instead, the interesting data must be moved first into the ath11k_skb_cb
      and ieee80211_tx_info.control must then not be used anymore.
      
      Tested-on: IPQ8074 hw2.0 WLAN.HK.2.4.0.1.r1-00026-QCAHKSWPL_SILICONZ-2
      
      Fixes: d5c65159 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
      Signed-off-by: default avatarSven Eckelmann <sven@narfation.org>
      Signed-off-by: default avatarKalle Valo <kvalo@codeaurora.org>
      Link: https://lore.kernel.org/r/20201119154235.263250-1-sven@narfation.org
      f4d291b4
  2. 24 Nov, 2020 4 commits
  3. 23 Nov, 2020 4 commits
  4. 20 Nov, 2020 1 commit
  5. 18 Nov, 2020 2 commits
  6. 10 Nov, 2020 2 commits
  7. 07 Nov, 2020 25 commits