[PATCH 0/3] wifi: ath10k/ath11k: firmware recovery deadlock and stale scan timeouts

[PATCH 0/3] wifi: ath10k/ath11k: firmware recovery deadlock and stale scan timeouts

[Christopher Griffin via B4 Relay]

On an Arista C-360 (IPQ8074 with two QCN9074), a QCN9074 firmware crash
was never recovered. Patch 1 removes a conf_mutex deadlock between
ath11k_mac_op_start() and the restart work, which makes every recovery
time out when CONFIG_ATH11K_SPECTRAL is set.

The same crash left a scan timeout pending for a scan that had failed to
start, and it fired on freed memory after the driver was bound again.
Patch 2 stops arming it, and patch 3 does the same in ath10k, which has
the same code.

Tested on an Arista C-360 with the series applied to the ath11k of
OpenWrt's backports-7.2: before patch 1, two simulated asserts of the
QCN9074 firmware both ended in "Hardware became unavailable during
restart"; with it, two of two recovered in about 3 s. Patches 2
and 3 are compile-tested only (W=1); no scan failed to start in these
runs.

---
Christopher Griffin (3):
      wifi: ath11k: don't hold conf_mutex while waiting for recovery
      wifi: ath11k: don't arm the scan timeout for a scan that did not start
      wifi: ath10k: don't arm the scan timeout for a scan that did not start

 drivers/net/wireless/ath/ath10k/mac.c | 1 +
 drivers/net/wireless/ath/ath11k/mac.c | 6 ++++++
 2 files changed, 7 insertions(+)
---
base-commit: 5c8eab13e391aaabd5a1ad58f3ee4bb10ce7573e
change-id: 20261105-ath-recovery-scan-timeout-57a3b3dd7a6f

Best regards,
--  
Christopher Griffin <christophergriffin05@gmail.com>

[PATCH 1/3] wifi: ath11k: don't hold conf_mutex while waiting for recovery

[Christopher Griffin via B4 Relay]

From: Christopher Griffin <christophergriffin05@gmail.com>

After a firmware crash, mac80211's restart calls ath11k_mac_op_start(),
which waits in ath11k_mac_wait_reconfigure(), for up to
ATH11K_RECONFIGURE_TIMEOUT_HZ (10 s), for the restart work to finish
ath11k_core_reconfigure_on_crash(). It waits with ar->conf_mutex held.
But ath11k_core_reconfigure_on_crash() calls ath11k_spectral_deinit(),
which takes ar->conf_mutex on each radio where spectral scan is
enabled.

The wait came with commit 38194f3a605e ("ath11k: add synchronization
operation between reconfigure of mac80211 and ath11k_base"), the lock
in ath11k_spectral_deinit() a month later with the commit in the Fixes
tag.

So with CONFIG_ATH11K_SPECTRAL the restart work blocks until the wait
times out. op_start() then sends WMI commands while
ATH11K_FLAG_CRASH_FLUSH is still set, they fail with -ESHUTDOWN, and
mac80211 gives up on the radio. Recovery never succeeds.

Seen on a QCN9074 after simulate_fw_crash (debug_mask 0x1060). Firmware
start, the restart work's first step after the deinit, ran only once
op_start() had timed out and dropped the mutex:

  [  146.881170] ath11k_pci 0001:01:00.0: qmi firmware init done
  [  156.651121] ath11k_pci 0001:01:00.0: failed to send WMI_PDEV_SET_PARAM cmd
  [  156.651173] ath11k_pci 0001:01:00.0: failed to enable PMF QOS: (-108
  [  156.658853] ath11k_pci 0001:01:00.0: qmi firmware start
  [  156.663443] Hardware became unavailable during restart.

Drop conf_mutex across the wait. During the restart, op_start() runs
with the wiphy mutex held, so no other mac80211 callback can come in
meanwhile.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.5.r4-00683-QCAHKSWPL_SILICONZ-1

Fixes: 161c64de239c ("ath11k: disable spectral scan during spectral deinit")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Christopher Griffin <christophergriffin05@gmail.com>
---
 drivers/net/wireless/ath/ath11k/mac.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 1a237adaa37d1..5e4bb0ad057dd 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -6645,7 +6645,12 @@ static int ath11k_mac_op_start(struct ieee80211_hw *hw)
 		break;
 	case ATH11K_STATE_RESTARTING:
 		ar->state = ATH11K_STATE_RESTARTED;
+		/* The restart work takes conf_mutex (spectral deinit), so
+		 * don't hold it while waiting for that work to finish.
+		 */
+		mutex_unlock(&ar->conf_mutex);
 		ath11k_mac_wait_reconfigure(ab);
+		mutex_lock(&ar->conf_mutex);
 		break;
 	case ATH11K_STATE_RESTARTED:
 	case ATH11K_STATE_WEDGED:

-- 
2.43.0

[PATCH 2/3] wifi: ath11k: don't arm the scan timeout for a scan that did not start

[Christopher Griffin via B4 Relay]

From: Christopher Griffin <christophergriffin05@gmail.com>

When ath11k_start_scan() fails, ath11k_mac_op_hw_scan() sets the scan
state back to idle and returns the error to mac80211, but first still
queues ar->scan.timeout. The timeout then stays pending for the full
scan time (20 s by default) although no scan is running. A scan started
within that time gets no timeout of its own, as the work is already
pending, and the stale one aborts it early.

The stale timeout can also outlive the radio. On a QCN9074 whose
firmware crashed during a scan, recovery failed and the driver was
unbound and bound again; the failed scan's timeout then fired from the
freed ath11k:

  [  145.937344] ath11k_pci 0001:01:00.0: failed to start hw scan: -110
  [  166.251148] workqueue: cannot queue ath11k_scan_timeout_work [ath11k] on wq D@\x7f\xff \x05\xb6...
  [  166.254814] WARNING: CPU: 2 PID: 0 at kernel/workqueue.c:2292 __queue_work+0x3c4/0x4d8

Don't queue the timeout when the scan did not start, as
ath11k_mac_op_remain_on_channel() and ath12k already do.

Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Christopher Griffin <christophergriffin05@gmail.com>
---
 drivers/net/wireless/ath/ath11k/mac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath11k/mac.c b/drivers/net/wireless/ath/ath11k/mac.c
index 5e4bb0ad057dd..291077c551476 100644
--- a/drivers/net/wireless/ath/ath11k/mac.c
+++ b/drivers/net/wireless/ath/ath11k/mac.c
@@ -4335,6 +4335,7 @@ static int ath11k_mac_op_hw_scan(struct ieee80211_hw *hw,
 		spin_lock_bh(&ar->data_lock);
 		ar->scan.state = ATH11K_SCAN_IDLE;
 		spin_unlock_bh(&ar->data_lock);
+		goto exit;
 	}
 
 	ieee80211_queue_delayed_work(ar->hw, &ar->scan.timeout,

-- 
2.43.0

[PATCH 3/3] wifi: ath10k: don't arm the scan timeout for a scan that did not start

[Christopher Griffin via B4 Relay]

From: Christopher Griffin <christophergriffin05@gmail.com>

When ath10k_start_scan() fails, ath10k_hw_scan() sets the scan state
back to idle and returns the error to mac80211, but first still queues
ar->scan.timeout. The timeout then stays pending for the full scan time
(20 s by default) although no scan is running. A scan started within
that time gets no timeout of its own, as the work is already pending,
and the stale one aborts it early.

Don't queue the timeout when the scan did not start, as
ath10k_remain_on_channel() already does. Until commit 634349bae0b2
("ath10k: move hw_scan worker queuing") ath10k_start_scan() queued it,
on success only.

ath11k has the same code; there, a QCN9074 firmware crash during a scan
left such a timeout pending.

Fixes: 634349bae0b2 ("ath10k: move hw_scan worker queuing")
Assisted-by: Claude:claude-opus-5-5
Signed-off-by: Christopher Griffin <christophergriffin05@gmail.com>
---
 drivers/net/wireless/ath/ath10k/mac.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
index 8e604697d6c20..2fded15b61721 100644
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -6491,6 +6491,7 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw,
 		spin_lock_bh(&ar->data_lock);
 		ar->scan.state = ATH10K_SCAN_IDLE;
 		spin_unlock_bh(&ar->data_lock);
+		goto exit;
 	}
 
 	ieee80211_queue_delayed_work(ar->hw, &ar->scan.timeout,

-- 
2.43.0

Re: [PATCH 3/3] wifi: ath10k: don't arm the scan timeout for a scan that did not start

[Loic Poulain]

On Thu, Nov 5, 2026 at 7:11 PM Christopher Griffin via B4 Relay
<devnull+christophergriffin05.gmail.com@kernel.org> wrote:
>
> From: Christopher Griffin <christophergriffin05@gmail.com>
>
> When ath10k_start_scan() fails, ath10k_hw_scan() sets the scan state
> back to idle and returns the error to mac80211, but first still queues
> ar->scan.timeout. The timeout then stays pending for the full scan time
> (20 s by default) although no scan is running. A scan started within
> that time gets no timeout of its own, as the work is already pending,
> and the stale one aborts it early.
>
> Don't queue the timeout when the scan did not start, as
> ath10k_remain_on_channel() already does. Until commit 634349bae0b2
> ("ath10k: move hw_scan worker queuing") ath10k_start_scan() queued it,
> on success only.
>
> ath11k has the same code; there, a QCN9074 firmware crash during a scan
> left such a timeout pending.
>
> Fixes: 634349bae0b2 ("ath10k: move hw_scan worker queuing")
> Assisted-by: Claude:claude-opus-5-5
> Signed-off-by: Christopher Griffin <christophergriffin05@gmail.com>

It looks more like a theoretical issue than something that is likely
to occur in practice, but the fix looks good to me.

Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com>

> ---
>  drivers/net/wireless/ath/ath10k/mac.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/net/wireless/ath/ath10k/mac.c b/drivers/net/wireless/ath/ath10k/mac.c
> index 8e604697d6c20..2fded15b61721 100644
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -6491,6 +6491,7 @@ static int ath10k_hw_scan(struct ieee80211_hw *hw,
>                 spin_lock_bh(&ar->data_lock);
>                 ar->scan.state = ATH10K_SCAN_IDLE;
>                 spin_unlock_bh(&ar->data_lock);
> +               goto exit;
>         }
>
>         ieee80211_queue_delayed_work(ar->hw, &ar->scan.timeout,
>
> --
> 2.43.0
>
>

Re: [PATCH 3/3] wifi: ath10k: don't arm the scan timeout for a scan that did not start

[Jeff Johnson]

On 11/5/2026 5:09 PM, Christopher Griffin wrote:
> On Thu, Nov 5, 2026 at 9:53 PM Loic Poulain <loic.poulain@oss.qualcomm.com
> <mailto:loic.poulain@oss.qualcomm.com>> wrote:
>> It looks more like a theoretical issue than something that is likely
>> to occur in practice, but the fix looks good to me.
>>
>> Reviewed-by: Loic Poulain <loic.poulain@oss.qualcomm.com
> <mailto:loic.poulain@oss.qualcomm.com>>
> 
> Thanks for the review, Loic.
> 
> We did hit it on ath11k, and it did damage: on a QCN9074, a firmware
> crash failed a scan start with -110, the timeout was armed anyway, and
> it fired after the dead radio had been unbound, ending in "cannot queue
> ath11k_scan_timeout_work on wq" with a garbage workqueue, and a panic
> (that is patch 2/3).
> 
> Whether ath10k ever hits it I don't know, but the code is the same, so
> the fix can't hurt.
> 
> Christopher Griffin

Please don't send HTML e-mail.

Note your reply was not archived or sent to the mailing list because it was
HTML. I only received it since I was directly addressed.

You can see it is not captured in the thread:
https://lore.kernel.org/all/20261105-ath-recovery-scan-timeout-v1-0-99a70d89e114@gmail.com/

/jeff