1. 22 Sep, 2022 3 commits
    • Wen Gong's avatar
      wifi: ath10k: reset pointer after memory free to avoid potential use-after-free · 1e1cb8e0
      Wen Gong authored
      When running suspend test, kernel crash happened in ath10k, and it is
      fixed by commit b72a4aff ("ath10k: skip ath10k_halt during suspend
      for driver state RESTARTING").
      
      Currently the crash is fixed, but as a common code style, it is better
      to set the pointer to NULL after memory is free.
      
      This is to address the code style and it will avoid potential bug of
      use-after-free.
      
      Tested-on: QCA6174 hw3.2 PCI WLAN.RM.4.4.1-00110-QCARMSWP-1
      Signed-off-by: default avatarWen Gong <quic_wgong@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220505092248.787-1-quic_wgong@quicinc.com
      1e1cb8e0
    • Wen Gong's avatar
      wifi: ath11k: fix failed to find the peer with peer_id 0 when disconnected · a20ed60b
      Wen Gong authored
      It has a fail log which is ath11k_dbg in ath11k_dp_rx_process_mon_status(),
      as below, it will not print when debug_mask is not set ATH11K_DBG_DATA.
      	ath11k_dbg(ab, ATH11K_DBG_DATA,
      		  "failed to find the peer with peer_id %d\n",
      		   ppdu_info.peer_id);
      
      When run scan with station disconnected, the peer_id is 0 for case
      HAL_RX_MPDU_START in ath11k_hal_rx_parse_mon_status_tlv() which called
      from ath11k_dp_rx_process_mon_status(), and the peer_id of ppdu_info is
      reset to 0 in the while loop, so it does not match condition of the
      check "if (ppdu_info->peer_id == HAL_INVALID_PEERID" in the loop, and
      then the log "failed to find the peer with peer_id 0" print after the
      check in the loop, it is below call stack when debug_mask is set
      ATH11K_DBG_DATA.
      
      The reason is this commit 01d2f285 ("ath11k: decode HE status tlv")
      add "memset(ppdu_info, 0, sizeof(struct hal_rx_mon_ppdu_info))" in
      ath11k_dp_rx_process_mon_status(), but the commit does not initialize
      the peer_id to HAL_INVALID_PEERID, then lead the check mis-match.
      
      Callstack of the failed log:
      [12335.689072] RIP: 0010:ath11k_dp_rx_process_mon_status+0x9ea/0x1020 [ath11k]
      [12335.689157] Code: 89 ff e8 f9 10 00 00 be 01 00 00 00 4c 89 f7 e8 dc 4b 4e de 48 8b 85 38 ff ff ff c7 80 e4 07 00 00 01 00 00 00 e9 20 f8 ff ff <0f> 0b 41 0f b7 96 be 06 00 00 48 c7 c6 b8 50 44 c1 4c 89 ff e8 fd
      [12335.689180] RSP: 0018:ffffb874001a4ca0 EFLAGS: 00010246
      [12335.689210] RAX: 0000000000000000 RBX: ffff995642cbd100 RCX: 0000000000000000
      [12335.689229] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff99564212cd18
      [12335.689248] RBP: ffffb874001a4dc0 R08: 0000000000000001 R09: 0000000000000000
      [12335.689268] R10: 0000000000000220 R11: ffffb874001a48e8 R12: ffff995642473d40
      [12335.689286] R13: ffff99564212c5b8 R14: ffff9956424736a0 R15: ffff995642120000
      [12335.689303] FS:  0000000000000000(0000) GS:ffff995739000000(0000) knlGS:0000000000000000
      [12335.689323] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      [12335.689341] CR2: 00007f43c5d5e039 CR3: 000000011c012005 CR4: 00000000000606e0
      [12335.689360] Call Trace:
      [12335.689377]  <IRQ>
      [12335.689418]  ? rcu_read_lock_held_common+0x12/0x50
      [12335.689447]  ? rcu_read_lock_sched_held+0x25/0x80
      [12335.689471]  ? rcu_read_lock_held_common+0x12/0x50
      [12335.689504]  ath11k_dp_rx_process_mon_rings+0x8d/0x4f0 [ath11k]
      [12335.689578]  ? ath11k_dp_rx_process_mon_rings+0x8d/0x4f0 [ath11k]
      [12335.689653]  ? lock_acquire+0xef/0x360
      [12335.689681]  ? rcu_read_lock_sched_held+0x25/0x80
      [12335.689713]  ath11k_dp_service_mon_ring+0x38/0x60 [ath11k]
      [12335.689784]  ? ath11k_dp_rx_process_mon_rings+0x4f0/0x4f0 [ath11k]
      [12335.689860]  call_timer_fn+0xb2/0x2f0
      [12335.689897]  ? ath11k_dp_rx_process_mon_rings+0x4f0/0x4f0 [ath11k]
      [12335.689970]  run_timer_softirq+0x21f/0x540
      [12335.689999]  ? ktime_get+0xad/0x160
      [12335.690025]  ? lapic_next_deadline+0x2c/0x40
      [12335.690053]  ? clockevents_program_event+0x82/0x100
      [12335.690093]  __do_softirq+0x151/0x4a8
      [12335.690135]  irq_exit_rcu+0xc9/0x100
      [12335.690165]  sysvec_apic_timer_interrupt+0xa8/0xd0
      [12335.690189]  </IRQ>
      [12335.690204]  <TASK>
      [12335.690225]  asm_sysvec_apic_timer_interrupt+0x12/0x20
      
      Reset the default value to HAL_INVALID_PEERID each time after memset
      of ppdu_info as well as others memset which existed in function
      ath11k_dp_rx_process_mon_status(), then the failed log disappeared.
      
      Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
      
      Fixes: 01d2f285 ("ath11k: decode HE status tlv")
      Signed-off-by: default avatarWen Gong <quic_wgong@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220518033556.31940-1-quic_wgong@quicinc.com
      a20ed60b
    • Wen Gong's avatar
      wifi: ath11k: change complete() to complete_all() for scan.completed · 7855a6ed
      Wen Gong authored
      Currently commit 1f682dc9 ("ath11k: reduce the wait time of 11d scan
      and hw scan while add interface") introduced a wait_for_completion_timeout
      operation for ar->scan.completed, another one is existed in ath11k_scan_stop(),
      then ath11k has two places to wait for the ar->scan.completed and they
      run in different thread, thus it is possible to happend that the two
      thread both enter wait status. To handle this scenario, ath11k should
      change the complete() to complete_all() for the ar->scan.completed. This
      also work well when it is only one thread wait for ar->scan.completed.
      
      Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3
      Signed-off-by: default avatarWen Gong <quic_wgong@quicinc.com>
      Signed-off-by: default avatarKalle Valo <quic_kvalo@quicinc.com>
      Link: https://lore.kernel.org/r/20220919024413.25083-1-quic_wgong@quicinc.com
      7855a6ed
  2. 19 Sep, 2022 5 commits
  3. 16 Sep, 2022 3 commits
  4. 10 Sep, 2022 6 commits
  5. 07 Sep, 2022 1 commit
  6. 02 Sep, 2022 3 commits
  7. 01 Sep, 2022 3 commits
  8. 30 Aug, 2022 2 commits
  9. 29 Aug, 2022 1 commit
  10. 26 Aug, 2022 13 commits