Re: [PATCH] wifi: ath11k: fix warning when unbinding

Re: [PATCH] wifi: ath11k: fix warning when unbinding

[Rameshkumar Sundaram]

On 4/20/2026 4:31 PM, Jose Ignacio Tornos Martinez wrote:
> If there is an error during some initialization related to firmware,
> the buffers dp->tx_ring[i].tx_status are released.
> However this is released again when the device is unbinded (ath11k_pci),
> and we get:
> WARNING: CPU: 0 PID: 6231 at mm/slub.c:4368 free_large_kmalloc+0x57/0x90
> Call Trace:
> free_large_kmalloc
> ath11k_dp_free
> ath11k_core_deinit
> ath11k_pci_remove
> ...
> 
> The issue is always reproducible from a VM because the MSI addressing
> initialization is failing.
> 
> In order to fix the issue, just set the buffers to NULL after releasing in
> order to avoid the double free.
> 
> Fixes: d5c65159f289 ("ath11k: driver for Qualcomm IEEE 802.11ax devices")
> Cc: stable@vger.kernel.org
> Signed-off-by: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
> ---
>   drivers/net/wireless/ath/ath11k/dp.c | 1 +
>   1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/wireless/ath/ath11k/dp.c b/drivers/net/wireless/ath/ath11k/dp.c
> index bbb86f165141..5a50b623bd07 100644
> --- a/drivers/net/wireless/ath/ath11k/dp.c
> +++ b/drivers/net/wireless/ath/ath11k/dp.c
> @@ -1040,6 +1040,7 @@ void ath11k_dp_free(struct ath11k_base *ab)
>   		idr_destroy(&dp->tx_ring[i].txbuf_idr);
>   		spin_unlock_bh(&dp->tx_ring[i].tx_idr_lock);
>   		kfree(dp->tx_ring[i].tx_status);
> +		dp->tx_ring[i].tx_status = NULL;
>   	}
>   
>   	/* Deinit any SOC level resource */

On which hardware did you observe this issue? is it QCA6390, WCN6855, 
QCA2066 or QCA6698AQ ? Also, where do you see the initial failure ? Is 
it somewhere in ath11k_core_qmi_firmware_ready() ?

I am asking because this looks like it may be exposed by commit 
6fe62a8cec51 ("wifi: ath11k: Add cold boot calibration support on 
WCN6750") [1]. That commit added the ATH11K_QMI_EVENT_FW_READY path, but 
the return value from ath11k_core_qmi_firmware_ready() is not handled 
there. If that call fails after ath11k_dp_free() has already run on the 
error path, ATH11K_FLAG_QMI_FAIL is not set. Later, ath11k_pci_remove() 
does not take the QMI-fail cleanup path and calls ath11k_core_deinit(), 
which calls ath11k_dp_free() and other cleanup functions again.

This is similar to the failure case fixed earlier by a19c0e104db9
("ath11k: Handle failure in qmi firmware ready") [2], where failure from
ath11k_core_qmi_firmware_ready() needed to be handled.


[1] 
https://lore.kernel.org/r/20220720134909.15626-3-quic_mpubbise@quicinc.com
[2] 
https://lore.kernel.org/r/1645079195-13564-1-git-send-email-quic_seevalam@quicinc.com



--
Ramesh

Re: [PATCH] wifi: ath11k: fix warning when unbinding

[Jose Ignacio Tornos Martinez]

Hello Rameshkumar,

The hardwre that I am using is QCNFA765, but I think it is something
related to ath11k driver and not related to some specific hardware.

I am running with the latest upstream kernel and I can reproduce it, so
I think it is not related with the problems that you comment.

Let me repeat this to try to clarify:

The easiest way to reproduce it is to run in a VM the default upstream
kernel (with this card using PCI passthrough), and since this is always
failing, just unbind the device (ath11k_pci).

The same problem was fixed by me for ath12k driver here ca68ce0d9f4b
("wifi: ath12k: fix warning when unbinding"), and I have seen the same
problem is also happening for ath11k driver.

Thanks

Best regards
José Ignacio

Re: [PATCH] wifi: ath11k: fix warning when unbinding

[Rameshkumar Sundaram]

On 5/7/2026 12:38 PM, Jose Ignacio Tornos Martinez wrote:
> Hello Rameshkumar,
> 
> The hardwre that I am using is QCNFA765, but I think it is something
> related to ath11k driver and not related to some specific hardware.
> 
> I am running with the latest upstream kernel and I can reproduce it, so
> I think it is not related with the problems that you comment.
> 
> Let me repeat this to try to clarify:
> 
> The easiest way to reproduce it is to run in a VM the default upstream
> kernel (with this card using PCI passthrough), and since this is always
> failing, just unbind the device (ath11k_pci).


What is the exact failure? Do you see any driver error logs when it occurs?

> 
> The same problem was fixed by me for ath12k driver here ca68ce0d9f4b
> ("wifi: ath12k: fix warning when unbinding"), and I have seen the same
> problem is also happening for ath11k driver.
> 

Got it. I was just thinking along with the proposed fix — whether we 
might also need to handle the sequencing on QMI failure.
In other words, do you think the issue(double free) would still be 
reproducible if we include a change like below ?

index 1397756d6251..5bbb53a6b404 100644
--- a/drivers/net/wireless/ath/ath11k/qmi.c
+++ b/drivers/net/wireless/ath/ath11k/qmi.c
@@ -3295,7 +3295,11 @@ static void ath11k_qmi_driver_event_work(struct 
work_struct *work)
                         clear_bit(ATH11K_FLAG_CRASH_FLUSH,
                                   &ab->dev_flags);
                         clear_bit(ATH11K_FLAG_RECOVERY, &ab->dev_flags);
-                       ath11k_core_qmi_firmware_ready(ab);
+                       ret = ath11k_core_qmi_firmware_ready(ab);
+                       if (ret) {
+                               set_bit(ATH11K_FLAG_QMI_FAIL, 
&ab->dev_flags);
+                               break;
+                       }
                         set_bit(ATH11K_FLAG_REGISTERED, &ab->dev_flags);

                         break;



--
Ramesh

Re: [PATCH] wifi: ath11k: fix warning when unbinding

[Jose Ignacio Tornos Martinez]

Hello Rameshkumar,

> What is the exact failure? Do you see any driver error logs when it occurs?
No error log, just the warning.

> Got it. I was just thinking along with the proposed fix — whether we
> might also need to handle the sequencing on QMI failure.
> In other words, do you think the issue(double free) would still be
> reproducible if we include a change like below ?
Yes, I think so and in addition the code is more robust.

There is no need to handle other stuff, the device can be bound again with
no problem.

Thanks

Best regards
José Ignacio