From: Jose Ignacio Tornos Martinez <jtornosm@redhat.com>
To: jtornosm@redhat.com
Cc: ath11k@lists.infradead.org, jjohnson@kernel.org,
linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
rameshkumar.sundaram@oss.qualcomm.com, stable@vger.kernel.org
Subject: Re: [PATCH] wifi: ath11k: fix warning when unbinding
Date: Thu, 14 May 2026 08:18:40 +0200 [thread overview]
Message-ID: <20260514061841.9517-1-jtornosm@redhat.com> (raw)
In-Reply-To: <20260507070808.367442-1-jtornosm@redhat.com>
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
next prev parent reply other threads:[~2026-05-14 6:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-20 11:01 [PATCH] wifi: ath11k: fix warning when unbinding Jose Ignacio Tornos Martinez
2026-04-28 2:28 ` Baochen Qiang
2026-04-29 5:14 ` Jose Ignacio Tornos Martinez
2026-04-29 7:23 ` Baochen Qiang
2026-05-06 18:19 ` Rameshkumar Sundaram
2026-05-07 7:08 ` Jose Ignacio Tornos Martinez
2026-05-08 10:17 ` Rameshkumar Sundaram
2026-05-08 10:31 ` Jose Ignacio Tornos Martinez
2026-05-14 4:54 ` Rameshkumar Sundaram
2026-05-14 6:18 ` Jose Ignacio Tornos Martinez [this message]
2026-05-14 6:55 ` Rameshkumar Sundaram
2026-05-14 8:15 ` Baochen Qiang
2026-05-15 2:27 ` Rameshkumar Sundaram
2026-05-15 6:39 ` Baochen Qiang
2026-05-14 6:56 ` Rameshkumar Sundaram
2026-05-15 6:40 ` Baochen Qiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260514061841.9517-1-jtornosm@redhat.com \
--to=jtornosm@redhat.com \
--cc=ath11k@lists.infradead.org \
--cc=jjohnson@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-wireless@vger.kernel.org \
--cc=rameshkumar.sundaram@oss.qualcomm.com \
--cc=stable@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.