[PATCH] wifi: ath11k: fix warning when unbinding

[PATCH] wifi: ath11k: fix warning when unbinding

[Jose Ignacio Tornos Martinez]

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 */
-- 
2.53.0

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

[Baochen Qiang]

On 4/20/2026 7:01 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.

MSI initialization runs at probe time but I don't see an error path doing
dp->tx_ring[i].tx_status release. So can you help elaborate? what is the call path when
the dp->tx_ring[i].tx_status is first released?

> 
> 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 */

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

[Jose Ignacio Tornos Martinez]

Hello Baochen,

As I try to comment in the commit description, the warning is not at
the intialization, but comes up when the device is unbinded after a
problem at the initialization stage, because due to the problem the
buffers were released (probe). Later after the problem, if the unbinding
is commanded the buffers are released again.
Setting to NUll after releasing avoids the double free.

The easiest way to reproduce it is to run in a VM the default upstream
kernel (that is always failing on VMs) and 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

[Baochen Qiang]

On 4/29/2026 1:14 PM, Jose Ignacio Tornos Martinez wrote:
> Hello Baochen,
> 
> As I try to comment in the commit description, the warning is not at
> the intialization, but comes up when the device is unbinded after a
> problem at the initialization stage, because due to the problem the
> buffers were released (probe). Later after the problem, if the unbinding
> is commanded the buffers are released again.
> Setting to NUll after releasing avoids the double free.
> 

OK, seems the first release happens during the error handling path of
ath11k_core_qmi_firmware_ready().

> The easiest way to reproduce it is to run in a VM the default upstream
> kernel (that is always failing on VMs) and 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 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

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

[Rameshkumar Sundaram]

On 5/8/2026 4:01 PM, Jose Ignacio Tornos Martinez wrote:
> 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.
> 

I agree that setting tx_status to NULL makes ath11k_dp_free() more
defensive, and it matches the ath12k fix.

However, i am still wondering how the second ath11k_dp_free() is reached 
if ATH11K_FLAG_QMI_FAIL is set.

In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:

     ath11k_pci_remove()
       ath11k_core_deinit()
         ath11k_core_soc_destroy()
           ath11k_dp_free()

should not run.

So if the double free is still reproducible with QMI_FAIL set (with the 
change i proposed), either the flag is not actually set in this failure 
case, or there is another path calling ath11k_dp_free() ?


--
Ramesh

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

[Jose Ignacio Tornos Martinez]

Hello Rameshkumar,

> I agree that setting tx_status to NULL makes ath11k_dp_free() more
> defensive, and it matches the ath12k fix.
Ok, I agree too.

> However, i am still wondering how the second ath11k_dp_free() is reached 
> if ATH11K_FLAG_QMI_FAIL is set.
>
> In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
> qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:
>
>     ath11k_pci_remove()
>       ath11k_core_deinit()
>         ath11k_core_soc_destroy()
>           ath11k_dp_free()
>
> should not run.
>
> So if the double free is still reproducible with QMI_FAIL set (with the 
> change i proposed), either the flag is not actually set in this failure 
> case, or there is another path calling ath11k_dp_free() ?
Let me try to clarify the issue more.
There are two error actions:
- First the previous error. I reproduce the situation as I commented: running
in a VM the default upstream kernel (with this card using PCI passthrough),
since this is always failing. Let me show the logs in this situation:
[   15.906564] ath11k_pci 0000:07:00.0: BAR 0 [mem 0xfdc00000-0xfddfffff 64bit]: assigned
[   15.926520] ath11k_pci 0000:07:00.0: MSI vectors: 32
[   15.928572] ath11k_pci 0000:07:00.0: wcn6855 hw2.0
[   16.984192] ath11k_pci 0000:07:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id 0x400c0200
[   16.984351] ath11k_pci 0000:07:00.0: fw_version 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
[   18.186971] ath11k_pci 0000:07:00.0: failed to receive control response completion, polling..
[   19.211036] ath11k_pci 0000:07:00.0: Service connect timeout
[   19.211815] ath11k_pci 0000:07:00.0: failed to connect to HTT: -110
[   19.214181] ath11k_pci 0000:07:00.0: failed to start core: -110
[   19.531989] ath11k_pci 0000:07:00.0: firmware crashed: MHI_CB_EE_RDDM
[   19.532930] ath11k_pci 0000:07:00.0: ignore reset dev flags 0xc000
[   29.259157] ath11k_pci 0000:07:00.0: failed to wait wlan mode request (mode 4): -110
[   29.259229] ath11k_pci 0000:07:00.0: qmi failed to send wlan mode off: -110
- Second after this, I commanded the unbinded (ath11_pci) and I get the
warning. Let extend here the stack trace:
[   24.238198]  ? free_large_kmalloc+0x57/0x90
[   24.238199]  ? report_bug+0x16b/0x180
[   24.238210]  ? handle_bug+0x3c/0x70
[   24.238218]  ? exc_invalid_op+0x14/0x70
[   24.238218]  ? asm_exc_invalid_op+0x16/0x20
[   24.238224]  ? free_large_kmalloc+0x57/0x90
[   24.238227]  ath11k_dp_free+0x99/0xb0 [ath11k]
[   24.238275]  ath11k_core_deinit+0x12b/0x1a0 [ath11k]
[   24.238287]  ath11k_pci_remove+0x7b/0x120 [ath11k_pci]
[   24.238294]  pci_device_remove+0x3e/0xb0
[   24.238304]  device_release_driver_internal+0x193/0x200
[   24.238315]  unbind_store+0x9d/0xb0
[   24.238320]  kernfs_fop_write_iter+0x13a/0x1d0
[   24.238330]  vfs_write+0x32e/0x470
[   24.238335]  ksys_write+0x5f/0xe0
[   24.238336]  do_syscall_64+0x5f/0xe0
Very easy to reproduce.

Anyway, although you can avoid a specific path, IMHO this small fix is
recommendable to avoid other similar situations.

Thanks

Best regards
José Ignacio

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

[Rameshkumar Sundaram]

On 5/14/2026 11:48 AM, Jose Ignacio Tornos Martinez wrote:
> Hello Rameshkumar,
> 
>> I agree that setting tx_status to NULL makes ath11k_dp_free() more
>> defensive, and it matches the ath12k fix.
> Ok, I agree too.
> 
>> However, i am still wondering how the second ath11k_dp_free() is reached
>> if ATH11K_FLAG_QMI_FAIL is set.
>>
>> In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
>> qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:
>>
>>      ath11k_pci_remove()
>>        ath11k_core_deinit()
>>          ath11k_core_soc_destroy()
>>            ath11k_dp_free()
>>
>> should not run.
>>
>> So if the double free is still reproducible with QMI_FAIL set (with the
>> change i proposed), either the flag is not actually set in this failure
>> case, or there is another path calling ath11k_dp_free() ?
> Let me try to clarify the issue more.
> There are two error actions:
> - First the previous error. I reproduce the situation as I commented: running
> in a VM the default upstream kernel (with this card using PCI passthrough),
> since this is always failing. Let me show the logs in this situation:
> [   15.906564] ath11k_pci 0000:07:00.0: BAR 0 [mem 0xfdc00000-0xfddfffff 64bit]: assigned
> [   15.926520] ath11k_pci 0000:07:00.0: MSI vectors: 32
> [   15.928572] ath11k_pci 0000:07:00.0: wcn6855 hw2.0
> [   16.984192] ath11k_pci 0000:07:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id 0x400c0200
> [   16.984351] ath11k_pci 0000:07:00.0: fw_version 0x11088c35 fw_build_timestamp 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
> [   18.186971] ath11k_pci 0000:07:00.0: failed to receive control response completion, polling..
> [   19.211036] ath11k_pci 0000:07:00.0: Service connect timeout
> [   19.211815] ath11k_pci 0000:07:00.0: failed to connect to HTT: -110
> [   19.214181] ath11k_pci 0000:07:00.0: failed to start core: -110
> [   19.531989] ath11k_pci 0000:07:00.0: firmware crashed: MHI_CB_EE_RDDM
> [   19.532930] ath11k_pci 0000:07:00.0: ignore reset dev flags 0xc000
> [   29.259157] ath11k_pci 0000:07:00.0: failed to wait wlan mode request (mode 4): -110
> [   29.259229] ath11k_pci 0000:07:00.0: qmi failed to send wlan mode off: -110
> - Second after this, I commanded the unbinded (ath11_pci) and I get the
> warning. Let extend here the stack trace:
> [   24.238198]  ? free_large_kmalloc+0x57/0x90
> [   24.238199]  ? report_bug+0x16b/0x180
> [   24.238210]  ? handle_bug+0x3c/0x70
> [   24.238218]  ? exc_invalid_op+0x14/0x70
> [   24.238218]  ? asm_exc_invalid_op+0x16/0x20
> [   24.238224]  ? free_large_kmalloc+0x57/0x90
> [   24.238227]  ath11k_dp_free+0x99/0xb0 [ath11k]
> [   24.238275]  ath11k_core_deinit+0x12b/0x1a0 [ath11k]
> [   24.238287]  ath11k_pci_remove+0x7b/0x120 [ath11k_pci]
> [   24.238294]  pci_device_remove+0x3e/0xb0
> [   24.238304]  device_release_driver_internal+0x193/0x200
> [   24.238315]  unbind_store+0x9d/0xb0
> [   24.238320]  kernfs_fop_write_iter+0x13a/0x1d0
> [   24.238330]  vfs_write+0x32e/0x470
> [   24.238335]  ksys_write+0x5f/0xe0
> [   24.238336]  do_syscall_64+0x5f/0xe0
> Very easy to reproduce.
> 


Thanks much for the logs, that makes sense. The timestamps explain why 
my earlier reasoning did not match the trace: unbind reaches 
ath11k_pci_remove() before ATH11K_FLAG_QMI_FAIL is set by the QMI event 
worker as it is held up on wlan mode off qmi transaction, so remove 
still takes the normal ath11k_core_deinit() path.


--
Ramesh

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>

Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>

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

[Baochen Qiang]

On 5/14/2026 2:55 PM, Rameshkumar Sundaram wrote:
> On 5/14/2026 11:48 AM, Jose Ignacio Tornos Martinez wrote:
>> Hello Rameshkumar,
>>
>>> I agree that setting tx_status to NULL makes ath11k_dp_free() more
>>> defensive, and it matches the ath12k fix.
>> Ok, I agree too.
>>
>>> However, i am still wondering how the second ath11k_dp_free() is reached
>>> if ATH11K_FLAG_QMI_FAIL is set.
>>>
>>> In ath11k_pci_remove(), when ATH11K_FLAG_QMI_FAIL is set, we take the
>>> qmi_fail path and skip ath11k_core_deinit(). So the normal remove path:
>>>
>>>      ath11k_pci_remove()
>>>        ath11k_core_deinit()
>>>          ath11k_core_soc_destroy()
>>>            ath11k_dp_free()
>>>
>>> should not run.
>>>
>>> So if the double free is still reproducible with QMI_FAIL set (with the
>>> change i proposed), either the flag is not actually set in this failure
>>> case, or there is another path calling ath11k_dp_free() ?
>> Let me try to clarify the issue more.
>> There are two error actions:
>> - First the previous error. I reproduce the situation as I commented: running
>> in a VM the default upstream kernel (with this card using PCI passthrough),
>> since this is always failing. Let me show the logs in this situation:
>> [   15.906564] ath11k_pci 0000:07:00.0: BAR 0 [mem 0xfdc00000-0xfddfffff 64bit]: assigned
>> [   15.926520] ath11k_pci 0000:07:00.0: MSI vectors: 32
>> [   15.928572] ath11k_pci 0000:07:00.0: wcn6855 hw2.0
>> [   16.984192] ath11k_pci 0000:07:00.0: chip_id 0x2 chip_family 0xb board_id 0xff soc_id
>> 0x400c0200
>> [   16.984351] ath11k_pci 0000:07:00.0: fw_version 0x11088c35 fw_build_timestamp
>> 2024-04-17 08:34 fw_build_id WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.41
>> [   18.186971] ath11k_pci 0000:07:00.0: failed to receive control response completion,
>> polling..
>> [   19.211036] ath11k_pci 0000:07:00.0: Service connect timeout
>> [   19.211815] ath11k_pci 0000:07:00.0: failed to connect to HTT: -110
>> [   19.214181] ath11k_pci 0000:07:00.0: failed to start core: -110
>> [   19.531989] ath11k_pci 0000:07:00.0: firmware crashed: MHI_CB_EE_RDDM
>> [   19.532930] ath11k_pci 0000:07:00.0: ignore reset dev flags 0xc000
>> [   29.259157] ath11k_pci 0000:07:00.0: failed to wait wlan mode request (mode 4): -110
>> [   29.259229] ath11k_pci 0000:07:00.0: qmi failed to send wlan mode off: -110
>> - Second after this, I commanded the unbinded (ath11_pci) and I get the
>> warning. Let extend here the stack trace:
>> [   24.238198]  ? free_large_kmalloc+0x57/0x90
>> [   24.238199]  ? report_bug+0x16b/0x180
>> [   24.238210]  ? handle_bug+0x3c/0x70
>> [   24.238218]  ? exc_invalid_op+0x14/0x70
>> [   24.238218]  ? asm_exc_invalid_op+0x16/0x20
>> [   24.238224]  ? free_large_kmalloc+0x57/0x90
>> [   24.238227]  ath11k_dp_free+0x99/0xb0 [ath11k]
>> [   24.238275]  ath11k_core_deinit+0x12b/0x1a0 [ath11k]
>> [   24.238287]  ath11k_pci_remove+0x7b/0x120 [ath11k_pci]
>> [   24.238294]  pci_device_remove+0x3e/0xb0
>> [   24.238304]  device_release_driver_internal+0x193/0x200
>> [   24.238315]  unbind_store+0x9d/0xb0
>> [   24.238320]  kernfs_fop_write_iter+0x13a/0x1d0
>> [   24.238330]  vfs_write+0x32e/0x470
>> [   24.238335]  ksys_write+0x5f/0xe0
>> [   24.238336]  do_syscall_64+0x5f/0xe0
>> Very easy to reproduce.
>>
> 
> 
> Thanks much for the logs, that makes sense. The timestamps explain why my earlier
> reasoning did not match the trace: unbind reaches ath11k_pci_remove() before
> ATH11K_FLAG_QMI_FAIL is set by the QMI event worker as it is held up on wlan mode off qmi

how could QMI worker set this flag? the first failure happens in
ath12k_core_qmi_firmware_ready() and upon this failure the QMI worker just break out
without setting any flag, no?

> transaction, so remove still takes the normal ath11k_core_deinit() path.
> 
> 
> -- 
> Ramesh
>