* [PATCH] wifi: rtw88: Add NULL check for chip->edcca_th
From: Panagiotis Petrakopoulos @ 2026-04-13 10:02 UTC (permalink / raw)
To: pkshih; +Cc: linux-wireless, goainwo, Panagiotis Petrakopoulos
It was recently reported that rtw_fw_adaptivity_result
in fw.c dereferences rtwdev->chip->edcca_th without
a null check. The issue appears to be that devices
with the 8821CE chip don't define edcca_th in their
chip info. As a result, when rtw_fw_adaptivity_result
tries to dereference it, the kernel triggers an oops.
Add a NULL check for edcca_th before dereferencing
it in rtw_fw_adaptivity_result() in fw.c and
rtw_phy_set_edcca_th() in phy.c.
Tested on a 8822CE chip which defines edcca_th, so
this issue is not present on it, but it still uses
this driver and I can verify there are no regressions.
Reported-by: Oleksandr Havrylov <goainwo@gmail.com>
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221286
Link: https://lore.kernel.org/linux-wireless/CALdGYqQriS7mP0vj_rm_xvisfzFVh0hbpy+---48r6bodZO7tg@mail.gmail.com/
Signed-off-by: Panagiotis Petrakopoulos <npetrakopoulos2003@gmail.com>
---
drivers/net/wireless/realtek/rtw88/fw.c | 3 +++
drivers/net/wireless/realtek/rtw88/phy.c | 3 +++
2 files changed, 6 insertions(+)
diff --git a/drivers/net/wireless/realtek/rtw88/fw.c b/drivers/net/wireless/realtek/rtw88/fw.c
index 48207052e3f8..c4819ef6d54d 100644
--- a/drivers/net/wireless/realtek/rtw88/fw.c
+++ b/drivers/net/wireless/realtek/rtw88/fw.c
@@ -284,6 +284,9 @@ static void rtw_fw_adaptivity_result(struct rtw_dev *rtwdev, u8 *payload,
result->density, result->igi, result->l2h_th_init, result->l2h,
result->h2l, result->option);
+ if (!edcca_th)
+ return;
+
rtw_dbg(rtwdev, RTW_DBG_ADAPTIVITY, "Reg Setting: L2H %x H2L %x\n",
rtw_read32_mask(rtwdev, edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask),
diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
index e2ac5c6fd500..c10eb28e54ad 100644
--- a/drivers/net/wireless/realtek/rtw88/phy.c
+++ b/drivers/net/wireless/realtek/rtw88/phy.c
@@ -161,6 +161,9 @@ void rtw_phy_set_edcca_th(struct rtw_dev *rtwdev, u8 l2h, u8 h2l)
{
const struct rtw_hw_reg_offset *edcca_th = rtwdev->chip->edcca_th;
+ if (!edcca_th)
+ return;
+
rtw_write32_mask(rtwdev,
edcca_th[EDCCA_TH_L2H_IDX].hw_reg.addr,
edcca_th[EDCCA_TH_L2H_IDX].hw_reg.mask,
--
2.53.0
^ permalink raw reply related
* Re: [PATCH] mac80211_hwsim: change hwsim_class to a const struct
From: Jori Koolstra @ 2026-04-13 9:54 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg Kroah-Hartman, open list:MAC80211, open list
In-Reply-To: <2f2ddabe109c846d3635098a8004b3a5632aac45.camel@sipsolutions.net>
> Op 13-04-2026 08:19 CEST schreef Johannes Berg <johannes@sipsolutions.net>:
>
>
> On Sun, 2026-04-12 at 16:20 +0200, Jori Koolstra wrote:
> >
> >
> > I just saw that it has been already applied.
>
> I didn't apply this one though. You sent it twice:
>
> https://lore.kernel.org/all/20260303165938.3773998-1-jkoolstra@xs4all.nl/
> https://lore.kernel.org/all/20260401165938.3843784-1-jkoolstra@xs4all.nl/
>
I think then I might know what happened. The patch was applied but I was
not aware of it, so I resend it. Then you tried to apply it, but it was
not possible because it was already applied (I had to do a three-way merge).
But maybe I am totally mistaken here.
> and the *second* one didn't apply (and I replied to it accordingly.)
>
> But it looks like at that point I missed there was a first one (please
> add "v2" tags etc. when doing this),
I intended it as a resend.
>
> What's strange is that they look to be completely identical, so I don't
> know why one didn't apply and one did.
>
> johannes
Thanks,
Jori.
^ permalink raw reply
* Re: [PATCH 0/2] wifi: ath: Use static calibration variant table for devicetree platforms
From: Ernest Van Hoecke @ 2026-04-13 9:32 UTC (permalink / raw)
To: Baochen Qiang
Cc: Manivannan Sadhasivam, Jeff Johnson, Jeff Johnson, Johannes Berg,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, linux-wireless,
linux-kernel, ath10k, ath11k, devicetree, ath12k, Miaoqing Pan
In-Reply-To: <ff11954f-345f-4865-a86e-759aa167768d@oss.qualcomm.com>
On Wed, Apr 08, 2026 at 02:06:00PM +0800, Baochen Qiang wrote:
>
>
> On 11/25/2025 5:57 PM, Ernest Van Hoecke wrote:
> > On Tue, Nov 18, 2025 at 12:23:20PM +0530, Manivannan Sadhasivam wrote:
> >>
> >> ath12k doesn't seem to require a calibration variant. But even if the user
> >> replaces ath11k chipset with ath10k one, the calibration variant should be the
> >> same as it is platform specific except for WSI.
> >>
> >> - Mani
> >>
> >> --
> >> மணிவண்ணன் சதாசிவம்
> >>
> >
> > Hi all,
> >
> > Jumping in on this thread to ask about how we should handle variants.
> >
> > We are using the WCN7850 device with the ath12k driver and received three
> > board files for this from Silex, signed by Qualcomm. All three support the
> > same board (SX-PCEBE), where one is the board file to be used for the
> > US/EU/JP and the other two are one for higher emissions in the UK/CA and
> > one for lower emissions in the UK/CA.
> >
> > Since these are needed for regulatory differences but support the same
> > board, we were wondering about your views on how to handle that in
> > mainline. I see that there is no support for the board file selection in
> > the device tree for ath12k, and that there is some discussion on how to
> > handle variants in general. We are using a device tree-based setup and no
> > ACPI.
>
> does your machine has different 'model' property for different BDFs ?
> does the existing ath11k 'calibration' property based mechanism satisfy your requirement?
>
We have a SoM with always the same WiFi SoC on board. These SoMs are
then mated with a carrier board, in our case often a development board,
and together they form a whole machine for which we have a specific
device tree with a specific model and compatible name.
Customers that create their own carrier board would have their own
device tree with their own model string. These carrier board device
trees include the base SoM dtsi.
When these devices are sold in multiple markets, the model string is
thus not specific to it. For example, the same model string can be sold
in Japan and in Canada, with different regulatory requirements and thus
a different board file that needs to be used.
In short: no, the machine does not have a different model property for
different BDFs.
Similarly, the WCN7850 would also not have a different PCI ID in
different regions since the hardware sold is the same.
The existing ath11k calibration property did provide a way to specify in
the DT which BDF should be used, so in that way it can provide a
solution yes. Of course, with the drawback that the PCI device has to be
specified in the DT.
This would allow customers to ship their device with a different DT
based on the the target market and its regulatory requirements. Another
mechanism that allows them to specify which variant to use in SW/HW
in- or outside the device tree would also work.
Thanks for looking at this and kind regards,
Ernest
^ permalink raw reply
* Re: [patch 07/38] treewide: Consolidate cycles_t
From: Ojaswin Mujoo @ 2026-04-13 9:15 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik,
netdev, linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120318.045532623@kernel.org>
On Fri, Apr 10, 2026 at 02:19:03PM +0200, Thomas Gleixner wrote:
> Most architectures define cycles_t as unsigned long execpt:
>
> - x86 requires it to be 64-bit independent of the 32-bit/64-bit build.
>
> - parisc and mips define it as unsigned int
>
> parisc has no real reason to do so as there are only a few usage sites
> which either expand it to a 64-bit value or utilize only the lower
> 32bits.
>
> mips has no real requirement either.
>
> Move the typedef to types.h and provide a config switch to enforce the
> 64-bit type for x86.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> ---
> arch/Kconfig | 4 ++++
> arch/alpha/include/asm/timex.h | 3 ---
> arch/arm/include/asm/timex.h | 1 -
> arch/loongarch/include/asm/timex.h | 2 --
> arch/m68k/include/asm/timex.h | 2 --
> arch/mips/include/asm/timex.h | 2 --
> arch/nios2/include/asm/timex.h | 2 --
> arch/parisc/include/asm/timex.h | 2 --
> arch/powerpc/include/asm/timex.h | 4 +---
> arch/riscv/include/asm/timex.h | 2 --
> arch/s390/include/asm/timex.h | 2 --
> arch/sparc/include/asm/timex_64.h | 1 -
> arch/x86/Kconfig | 1 +
> arch/x86/include/asm/tsc.h | 2 --
> include/asm-generic/timex.h | 1 -
> include/linux/types.h | 6 ++++++
> 16 files changed, 12 insertions(+), 25 deletions(-)
>
<...>
> --- a/arch/powerpc/include/asm/timex.h
> +++ b/arch/powerpc/include/asm/timex.h
> @@ -11,9 +11,7 @@
> #include <asm/cputable.h>
> #include <asm/vdso/timebase.h>
>
> -typedef unsigned long cycles_t;
> -
> -static inline cycles_t get_cycles(void)
> +ostatic inline cycles_t get_cycles(void)
Hi Thomas, I'm in middle of testing this series on powerpc. In the meantime I
noticed that there's probably a small typo here (althrough this is fixed
later)
Regards,
ojaswin
> {
> return mftb();
> }
^ permalink raw reply
* Re: [patch 14/38] slub: Use prandom instead of get_cycles()
From: Harry Yoo (Oracle) @ 2026-04-13 9:07 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Vlastimil Babka, linux-mm, Arnd Bergmann, x86, Lu Baolu,
iommu, Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Shengming Hu
In-Reply-To: <20260410120318.525653921@kernel.org>
[Resending after fixing broken email headers]
On Fri, Apr 10, 2026 at 02:19:37PM +0200, Thomas Gleixner wrote:
> The decision whether to scan remote nodes is based on a 'random' number
> retrieved via get_cycles(). get_cycles() is about to be removed.
>
> There is already prandom state in the code, so use that instead.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: linux-mm@kvack.org
> ---
Acked-by: Harry Yoo (Oracle) <harry@kernel.org>
Is this for this merge window?
This may conflict with upcoming changes on freelist shuffling [1]
(not queued for slab/for-next yet though), but it should be easy to
resolve.
[Cc'ing Shengming and SLAB ALLOCATOR folks]
[1] https://lore.kernel.org/linux-mm/20260409204352095kKWVYKtZImN59ybO6iRNj@zte.com.cn
--
Cheers,
Harry / Hyeonggon
> mm/slub.c | 37 +++++++++++++++++++++++--------------
> 1 file changed, 23 insertions(+), 14 deletions(-)
>
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3302,6 +3302,25 @@ static inline struct slab *alloc_slab_pa
> return slab;
> }
>
> +#if defined(CONFIG_SLAB_FREELIST_RANDOM) || defined(CONFIG_NUMA)
> +static DEFINE_PER_CPU(struct rnd_state, slab_rnd_state);
> +
> +static unsigned int slab_get_prandom_state(unsigned int limit)
> +{
> + struct rnd_state *state;
> + unsigned int res;
> +
> + /*
> + * An interrupt or NMI handler might interrupt and change
> + * the state in the middle, but that's safe.
> + */
> + state = &get_cpu_var(slab_rnd_state);
> + res = prandom_u32_state(state) % limit;
> + put_cpu_var(slab_rnd_state);
> + return res;
> +}
> +#endif
> +
> #ifdef CONFIG_SLAB_FREELIST_RANDOM
> /* Pre-initialize the random sequence cache */
> static int init_cache_random_seq(struct kmem_cache *s)
> @@ -3365,8 +3384,6 @@ static void *next_freelist_entry(struct
> return (char *)start + idx;
> }
>
> -static DEFINE_PER_CPU(struct rnd_state, slab_rnd_state);
> -
> /* Shuffle the single linked freelist based on a random pre-computed sequence */
> static bool shuffle_freelist(struct kmem_cache *s, struct slab *slab,
> bool allow_spin)
> @@ -3383,15 +3400,7 @@ static bool shuffle_freelist(struct kmem
> if (allow_spin) {
> pos = get_random_u32_below(freelist_count);
> } else {
> - struct rnd_state *state;
> -
> - /*
> - * An interrupt or NMI handler might interrupt and change
> - * the state in the middle, but that's safe.
> - */
> - state = &get_cpu_var(slab_rnd_state);
> - pos = prandom_u32_state(state) % freelist_count;
> - put_cpu_var(slab_rnd_state);
> + pos = slab_get_prandom_state(freelist_count);
> }
>
> page_limit = slab->objects * s->size;
> @@ -3882,7 +3891,7 @@ static void *get_from_any_partial(struct
> * with available objects.
> */
> if (!s->remote_node_defrag_ratio ||
> - get_cycles() % 1024 > s->remote_node_defrag_ratio)
> + slab_get_prandom_state(1024) > s->remote_node_defrag_ratio)
> return NULL;
>
> do {
> @@ -7102,7 +7111,7 @@ static unsigned int
>
> /* see get_from_any_partial() for the defrag ratio description */
> if (!s->remote_node_defrag_ratio ||
> - get_cycles() % 1024 > s->remote_node_defrag_ratio)
> + slab_get_prandom_state(1024) > s->remote_node_defrag_ratio)
> return 0;
>
> do {
> @@ -8421,7 +8430,7 @@ void __init kmem_cache_init_late(void)
> flushwq = alloc_workqueue("slub_flushwq", WQ_MEM_RECLAIM | WQ_PERCPU,
> 0);
> WARN_ON(!flushwq);
> -#ifdef CONFIG_SLAB_FREELIST_RANDOM
> +#if defined(CONFIG_SLAB_FREELIST_RANDOM) || defined(CONFIG_NUMA)
> prandom_init_once(&slab_rnd_state);
> #endif
> }
>
>
^ permalink raw reply
* Re: [patch 14/38] slub: Use prandom instead of get_cycles()
From: Vlastimil Babka (SUSE) @ 2026-04-13 9:00 UTC (permalink / raw)
To: Thomas Gleixner, LKML
Cc: linux-mm, Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik,
netdev, linux-wireless, Herbert Xu, linux-crypto, David Woodhouse,
Bernie Thompson, linux-fbdev, Theodore Tso, linux-ext4,
Andrew Morton, Uladzislau Rezki, Marco Elver, Dmitry Vyukov,
kasan-dev, Andrey Ryabinin, Thomas Sailer, linux-hams,
Jason A. Donenfeld, Richard Henderson, linux-alpha, Russell King,
linux-arm-kernel, Catalin Marinas, Huacai Chen, loongarch,
Geert Uytterhoeven, linux-m68k, Dinh Nguyen, Jonas Bonn,
linux-openrisc, Helge Deller, linux-parisc, Michael Ellerman,
linuxppc-dev, Paul Walmsley, linux-riscv, Heiko Carstens,
linux-s390, David S. Miller, sparclinux, Harry Yoo (Oracle),
Hao Li
In-Reply-To: <20260410120318.525653921@kernel.org>
On 4/10/26 14:19, Thomas Gleixner wrote:
> The decision whether to scan remote nodes is based on a 'random' number
> retrieved via get_cycles(). get_cycles() is about to be removed.
>
> There is already prandom state in the code, so use that instead.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: linux-mm@kvack.org
LGTM.
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
^ permalink raw reply
* [PATCH ath-next 1/1] wifi: ath12k: avoid deadlock in thermal read
From: Nicolas Escande @ 2026-04-13 8:38 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, maharaja.kennadyrajan
In-Reply-To: <20260413083807.1727905-1-nico.escande@gmail.com>
When removing the pci device we can have a deadlock if we try to read the
thermal sensor at the same time.
This is due to the fact that when the wiphy gets unregistered (so while
the wiphy lock is held), we wait for all sysfs operation to complete. But
if a read of the thermal device has been started in the mean time, we need
to acquire the wiphy lock, which will lead to a deadlock.
As we already have a flag indicating that we are currently unregistering
the device in the hw group, lets check it first (before locking) so we can
bail out early and avoid the dealock.
Signed-off-by: Nicolas Escande <nico.escande@gmail.com>
---
drivers/net/wireless/ath/ath12k/thermal.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/wireless/ath/ath12k/thermal.c b/drivers/net/wireless/ath/ath12k/thermal.c
index a764d2112a3c..700e7458ddff 100644
--- a/drivers/net/wireless/ath/ath12k/thermal.c
+++ b/drivers/net/wireless/ath/ath12k/thermal.c
@@ -17,9 +17,13 @@ static ssize_t ath12k_thermal_temp_show(struct device *dev,
char *buf)
{
struct ath12k *ar = dev_get_drvdata(dev);
+ struct ath12k_hw_group *ag = ath12k_ab_to_ag(ar->ab);
unsigned long time_left;
int ret, temperature;
+ if (!test_bit(ATH12K_GROUP_FLAG_REGISTERED, &ag->flags))
+ return -ESHUTDOWN;
+
guard(wiphy)(ath12k_ar_to_hw(ar)->wiphy);
if (ar->ah->state != ATH12K_HW_STATE_ON)
--
2.53.0
^ permalink raw reply related
* [PATCH ath-next 0/1] thermal read locking problem
From: Nicolas Escande @ 2026-04-13 8:38 UTC (permalink / raw)
To: ath12k; +Cc: linux-wireless, maharaja.kennadyrajan
So I hit a deadlock between ath12k_pci_remove() and reading the hwmon
temperature of the same device. See the stack trace bellow
[ 369.804971] INFO: task sh:7638 blocked for more than 122 seconds.
[ 369.804991] Not tainted 6.19.0git+ #15
[ 369.805000] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 369.805005] task:sh state:D stack:0 pid:7638 tgid:7638 ppid:7637 task_flags:0x480100 flags:0x00080800
[ 369.805022] Call Trace:
[ 369.805028] <TASK>
[ 369.805038] __schedule+0x45b/0x1780
[ 369.805057] ? rwsem_mark_wake+0x1a9/0x2c0
[ 369.805076] ? wake_up_q+0x37/0x90
[ 369.805090] schedule+0x27/0xd0
[ 369.805102] kernfs_drain+0xec/0x170
[ 369.805116] ? __pfx_autoremove_wake_function+0x10/0x10
[ 369.805130] __kernfs_remove.part.0+0x85/0x220
[ 369.805144] kernfs_remove+0x61/0x70
[ 369.805157] __kobject_del+0x2e/0xa0
[ 369.805167] kobject_del+0x13/0x30
[ 369.805175] device_del+0x283/0x3d0
[ 369.805185] ? rtnl_is_locked+0x15/0x20
[ 369.805200] wiphy_unregister+0x10a/0x3f0 [cfg80211 6168fbe3683cd298138328882cdf9008f30e4673]
[ 369.805417] ieee80211_unregister_hw+0x10c/0x130 [mac80211 a4ced2a7a5c741afca2c73dab2ee07ceec04d385]
[ 369.805625] ath12k_mac_hw_unregister+0x71/0x100 [ath12k 6ccd74c4d10a7837e98e0ec39774107bc2e6daf1]
[ 369.805746] ath12k_mac_unregister+0x2e/0x50 [ath12k 6ccd74c4d10a7837e98e0ec39774107bc2e6daf1]
[ 369.805895] ath12k_core_hw_group_stop+0x18/0xa0 [ath12k 6ccd74c4d10a7837e98e0ec39774107bc2e6daf1]
[ 369.805972] ath12k_core_hw_group_cleanup+0x37/0x90 [ath12k 6ccd74c4d10a7837e98e0ec39774107bc2e6daf1]
[ 369.806051] ath12k_pci_remove+0x60/0x110 [ath12k 6ccd74c4d10a7837e98e0ec39774107bc2e6daf1]
[ 369.806137] pci_device_remove+0x4a/0xc0
[ 369.806151] device_release_driver_internal+0x19e/0x200
[ 369.806165] unbind_store+0xa4/0xb0
[ 369.806179] kernfs_fop_write_iter+0x14d/0x200
[ 369.806194] vfs_write+0x25d/0x480
[ 369.806214] ksys_write+0x73/0xf0
[ 369.806228] do_syscall_64+0x11c/0x1610
[ 369.806242] ? __folio_mod_stat+0x2d/0x90
[ 369.806252] ? set_ptes.isra.0+0x36/0x80
[ 369.806266] ? do_anonymous_page+0xfb/0x830
[ 369.806276] ? __pte_offset_map+0x1b/0x100
[ 369.806291] ? __handle_mm_fault+0xb46/0xf60
[ 369.806310] ? count_memcg_events+0xd7/0x190
[ 369.806323] ? handle_mm_fault+0x1d7/0x2d0
[ 369.806356] ? do_user_addr_fault+0x21a/0x680
[ 369.806372] ? exc_page_fault+0x82/0x1d0
[ 369.806385] ? __irq_exit_rcu+0x4c/0xf0
[ 369.806397] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 369.806408] RIP: 0033:0x7f2d2d5163be
[ 369.806443] RSP: 002b:00007fff2b63ea90 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[ 369.806455] RAX: ffffffffffffffda RBX: 00007f2d2d66b580 RCX: 00007f2d2d5163be
[ 369.806462] RDX: 000000000000000d RSI: 0000561010670560 RDI: 0000000000000001
[ 369.806469] RBP: 00007fff2b63eaa0 R08: 0000000000000000 R09: 0000000000000000
[ 369.806476] R10: 0000000000000000 R11: 0000000000000202 R12: 000000000000000d
[ 369.806481] R13: 000000000000000d R14: 0000561010670560 R15: 0000561010670080
[ 369.806496] </TASK>
[ 369.806502] INFO: task cat:7652 blocked for more than 122 seconds.
[ 369.806512] Not tainted 6.19.0git+ #15
[ 369.806519] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 369.806524] task:cat state:D stack:0 pid:7652 tgid:7652 ppid:611 task_flags:0x400000 flags:0x00080000
[ 369.806538] Call Trace:
[ 369.806542] <TASK>
[ 369.806549] __schedule+0x45b/0x1780
[ 369.806565] ? page_counter_try_charge+0x90/0x150
[ 369.806580] ? mod_memcg_lruvec_state+0xc5/0x1f0
[ 369.806594] schedule+0x27/0xd0
[ 369.806621] schedule_preempt_disabled+0x15/0x30
[ 369.806634] __mutex_lock.constprop.0+0x545/0xae0
[ 369.806644] ? obj_cgroup_charge_account+0x23e/0x420
[ 369.806670] ath12k_thermal_temp_show+0x2b/0x130 [ath12k 6ccd74c4d10a7837e98e0ec39774107bc2e6daf1]
[ 369.806854] ? __kvmalloc_node_noprof+0x696/0x720
[ 369.806869] dev_attr_show+0x1f/0x50
[ 369.806909] sysfs_kf_seq_show+0xcc/0x120
[ 369.806921] seq_read_iter+0x128/0x490
[ 369.806947] ? rw_verify_area+0x56/0x180
[ 369.806959] vfs_read+0x268/0x390
[ 369.806970] ? __folio_mod_stat+0x2d/0x90
[ 369.806985] ksys_read+0x73/0xf0
[ 369.807010] do_syscall_64+0x11c/0x1610
[ 369.807028] ? count_memcg_events+0xd7/0x190
[ 369.807041] ? handle_mm_fault+0x1d7/0x2d0
[ 369.807060] ? do_user_addr_fault+0x21a/0x680
[ 369.807075] ? exc_page_fault+0x82/0x1d0
[ 369.807090] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 369.807099] RIP: 0033:0x7f2e4bd6d3be
[ 369.807139] RSP: 002b:00007ffcd412d410 EFLAGS: 00000202 ORIG_RAX: 0000000000000000
[ 369.807149] RAX: ffffffffffffffda RBX: 0000000000040000 RCX: 00007f2e4bd6d3be
[ 369.807156] RDX: 0000000000040000 RSI: 00007f2e4bc96000 RDI: 0000000000000003
[ 369.807162] RBP: 00007ffcd412d420 R08: 0000000000000000 R09: 0000000000000000
[ 369.807167] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffcd412d7a8
[ 369.807172] R13: 00007f2e4bc96000 R14: 0000000000040000 R15: 0000000000000000
[ 369.807204] </TASK>
This can be replicated at will on my side by force unbinding the driver
while reading in a loop:
- while [ true ]; do cat /sys/class/ieee80211/phy0/hwmon2/temp1_input; done
- echo 0000:01:00.0 > /sys/bus/pci/drivers/ath12k_wifi7_pci/unbind
I'm not sure if the way of fixing things is the best, but it works around
the deadlock in my tests.
Also as this is just in ath-next for now not sure if I should add a proper
fixes tag ?
Nicolas Escande (1):
wifi: ath12k: avoid deadlock in thermal read
drivers/net/wireless/ath/ath12k/thermal.c | 4 ++++
1 file changed, 4 insertions(+)
--
2.53.0
^ permalink raw reply
* (no subject)
From: Harry Yoo (Oracle) @ 2026-04-13 7:58 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Vlastimil Babka, linux-mm, Arnd Bergmann, x86, Lu Baolu,
iommu, Michael Grzeschik, netdev, linux-wireless, Herbert Xu,
linux-crypto, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux, Hao Li, Christoph Lameter, David Rientjes,
Roman Gushchin, Shengming Hu
Bcc:
Subject: Re: [patch 14/38] slub: Use prandom instead of get_cycles()
Reply-To:
In-Reply-To: <20260410120318.525653921@kernel.org>
On Fri, Apr 10, 2026 at 02:19:37PM +0200, Thomas Gleixner wrote:
> The decision whether to scan remote nodes is based on a 'random' number
> retrieved via get_cycles(). get_cycles() is about to be removed.
>
> There is already prandom state in the code, so use that instead.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: linux-mm@kvack.org
> ---
Acked-by: Harry Yoo (Oracle) <harry@kernel.org>
Is this for this merge window?
This may conflict with upcoming changes on freelist shuffling [1]
(not queued for slab/for-next yet though), but it should be easy to
resolve.
[Cc'ing Shengming and SLAB ALLOCATOR folks]
[1] https://lore.kernel.org/linux-mm/20260409204352095kKWVYKtZImN59ybO6iRNj@zte.com.cn
--
Cheers,
Harry / Hyeonggon
> mm/slub.c | 37 +++++++++++++++++++++++--------------
> 1 file changed, 23 insertions(+), 14 deletions(-)
>
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -3302,6 +3302,25 @@ static inline struct slab *alloc_slab_pa
> return slab;
> }
>
> +#if defined(CONFIG_SLAB_FREELIST_RANDOM) || defined(CONFIG_NUMA)
> +static DEFINE_PER_CPU(struct rnd_state, slab_rnd_state);
> +
> +static unsigned int slab_get_prandom_state(unsigned int limit)
> +{
> + struct rnd_state *state;
> + unsigned int res;
> +
> + /*
> + * An interrupt or NMI handler might interrupt and change
> + * the state in the middle, but that's safe.
> + */
> + state = &get_cpu_var(slab_rnd_state);
> + res = prandom_u32_state(state) % limit;
> + put_cpu_var(slab_rnd_state);
> + return res;
> +}
> +#endif
> +
> #ifdef CONFIG_SLAB_FREELIST_RANDOM
> /* Pre-initialize the random sequence cache */
> static int init_cache_random_seq(struct kmem_cache *s)
> @@ -3365,8 +3384,6 @@ static void *next_freelist_entry(struct
> return (char *)start + idx;
> }
>
> -static DEFINE_PER_CPU(struct rnd_state, slab_rnd_state);
> -
> /* Shuffle the single linked freelist based on a random pre-computed sequence */
> static bool shuffle_freelist(struct kmem_cache *s, struct slab *slab,
> bool allow_spin)
> @@ -3383,15 +3400,7 @@ static bool shuffle_freelist(struct kmem
> if (allow_spin) {
> pos = get_random_u32_below(freelist_count);
> } else {
> - struct rnd_state *state;
> -
> - /*
> - * An interrupt or NMI handler might interrupt and change
> - * the state in the middle, but that's safe.
> - */
> - state = &get_cpu_var(slab_rnd_state);
> - pos = prandom_u32_state(state) % freelist_count;
> - put_cpu_var(slab_rnd_state);
> + pos = slab_get_prandom_state(freelist_count);
> }
>
> page_limit = slab->objects * s->size;
> @@ -3882,7 +3891,7 @@ static void *get_from_any_partial(struct
> * with available objects.
> */
> if (!s->remote_node_defrag_ratio ||
> - get_cycles() % 1024 > s->remote_node_defrag_ratio)
> + slab_get_prandom_state(1024) > s->remote_node_defrag_ratio)
> return NULL;
>
> do {
> @@ -7102,7 +7111,7 @@ static unsigned int
>
> /* see get_from_any_partial() for the defrag ratio description */
> if (!s->remote_node_defrag_ratio ||
> - get_cycles() % 1024 > s->remote_node_defrag_ratio)
> + slab_get_prandom_state(1024) > s->remote_node_defrag_ratio)
> return 0;
>
> do {
> @@ -8421,7 +8430,7 @@ void __init kmem_cache_init_late(void)
> flushwq = alloc_workqueue("slub_flushwq", WQ_MEM_RECLAIM | WQ_PERCPU,
> 0);
> WARN_ON(!flushwq);
> -#ifdef CONFIG_SLAB_FREELIST_RANDOM
> +#if defined(CONFIG_SLAB_FREELIST_RANDOM) || defined(CONFIG_NUMA)
> prandom_init_once(&slab_rnd_state);
> #endif
> }
>
>
^ permalink raw reply
* [PATCH rtw-next] wifi: rtw88: fix wrong pci_get_drvdata type in AER handlers
From: Ping-Ke Shih @ 2026-04-13 6:59 UTC (permalink / raw)
To: linux-wireless; +Cc: timlee
From: Chin-Yen Lee <timlee@realtek.com>
rtw88 stores an ieee80211_hw pointer via pci_set_drvdata() at probe
time, but io_error_detected() and io_resume() retrieve it as a
net_device pointer. This causes netif_device_detach/attach to
operate on an ieee80211_hw struct, reading and writing at wrong
offsets.
Use ieee80211_stop_queues/wake_queues instead, consistent with
every other queue stop/start path in the driver.
Fixes: cdb82c80b934 ("wifi: rtw88: pci: add PCI Express error handling")
Signed-off-by: Chin-Yen Lee <timlee@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw88/pci.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/pci.c b/drivers/net/wireless/realtek/rtw88/pci.c
index bba370ad510c..c56beacbb1b0 100644
--- a/drivers/net/wireless/realtek/rtw88/pci.c
+++ b/drivers/net/wireless/realtek/rtw88/pci.c
@@ -1711,9 +1711,9 @@ static void rtw_pci_napi_deinit(struct rtw_dev *rtwdev)
static pci_ers_result_t rtw_pci_io_err_detected(struct pci_dev *pdev,
pci_channel_state_t state)
{
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = pci_get_drvdata(pdev);
- netif_device_detach(netdev);
+ ieee80211_stop_queues(hw);
return PCI_ERS_RESULT_NEED_RESET;
}
@@ -1730,12 +1730,12 @@ static pci_ers_result_t rtw_pci_io_slot_reset(struct pci_dev *pdev)
static void rtw_pci_io_resume(struct pci_dev *pdev)
{
- struct net_device *netdev = pci_get_drvdata(pdev);
+ struct ieee80211_hw *hw = pci_get_drvdata(pdev);
/* ack any pending wake events, disable PME */
pci_enable_wake(pdev, PCI_D0, 0);
- netif_device_attach(netdev);
+ ieee80211_wake_queues(hw);
}
const struct pci_error_handlers rtw_pci_err_handler = {
base-commit: fa489a77e3267e05df95db96ba98e141ec07cbd9
--
2.25.1
^ permalink raw reply related
* Re: [PATCH wireless-next 05/15] wifi: mac80211: Fix a kernel panic in ieee80211_encrypt_tx_skb()
From: Johannes Berg @ 2026-04-13 6:50 UTC (permalink / raw)
To: Miri Korenblit, linux-wireless; +Cc: Andrei Otcheretianski
In-Reply-To: <20260412121124.2246222-2-miriam.rachel.korenblit@intel.com>
> @@ -5370,7 +5370,14 @@ int ieee80211_encrypt_tx_skb(struct sk_buff *skb)
> __skb_queue_head_init(&tx.skbs);
> __skb_queue_tail(&tx.skbs, skb);
>
> - sdata = IEEE80211_DEV_TO_SUB_IF(skb->dev);
> + if (skb->dev)
> + sdata = IEEE80211_DEV_TO_SUB_IF(skb->dev);
> + else if (info->control.vif)
> + sdata = vif_to_sdata(info->control.vif);
> +
> + if (WARN_ON(!sdata))
> + return -EINVAL;
Can you get any more confused and defensive?
There's no point in not just using vif_to_sdata()?
johannes
^ permalink raw reply
* Re: [PATCH] mac80211_hwsim: change hwsim_class to a const struct
From: Johannes Berg @ 2026-04-13 6:19 UTC (permalink / raw)
To: Jori Koolstra; +Cc: Greg Kroah-Hartman, open list:MAC80211, open list
In-Reply-To: <675951732.2051008.1776003641276@kpc.webmail.kpnmail.nl>
On Sun, 2026-04-12 at 16:20 +0200, Jori Koolstra wrote:
>
>
> I just saw that it has been already applied.
I didn't apply this one though. You sent it twice:
https://lore.kernel.org/all/20260303165938.3773998-1-jkoolstra@xs4all.nl/
https://lore.kernel.org/all/20260401165938.3843784-1-jkoolstra@xs4all.nl/
and the *second* one didn't apply (and I replied to it accordingly.)
But it looks like at that point I missed there was a first one (please
add "v2" tags etc. when doing this), and then I later picked up that
first one because it had in fact compiled.
What's strange is that they look to be completely identical, so I don't
know why one didn't apply and one did.
johannes
^ permalink raw reply
* RE: [PATCH] wifi: rtw89: fix wrong pci_get_drvdata type in AER handlers
From: Ping-Ke Shih @ 2026-04-13 6:06 UTC (permalink / raw)
To: Christos Longros
Cc: linux-wireless@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <9f5dc9fa3b0747b1b07e27ac7ccf5443@realtek.com>
Ping-Ke Shih <pkshih@realtek.com> wrote:
> Christos Longros <chris.longros@gmail.com> wrote:
> > rtw89 stores an ieee80211_hw pointer via pci_set_drvdata() at probe
> > time, but io_error_detected() and io_resume() retrieve it as a
> > net_device pointer. This causes netif_device_detach/attach to
> > operate on an ieee80211_hw struct, reading and writing at wrong
> > offsets. The adjacent io_slot_reset() already does it correctly.
> >
> > Use ieee80211_stop_queues/wake_queues instead, consistent with
> > every other queue stop/start path in the driver.
> >
> > Tested on RTL8852CE by calling the handlers from a test module
> > before and after the fix.
>
> Could you share the "test module" you did? I'd like to know how to
> test (simulate) the io error.
>
> >
I'd add a Fixes tag
Fixes: 16e3d93c6183 ("wifi: rtw89: pci: add PCI Express error handling")
> > Signed-off-by: Christos Longros <chris.longros@gmail.com>
>
> Acked-by: Ping-Ke Shih <pkshih@realtek.com>
>
^ permalink raw reply
* RE: [PATCH] rtw88: add TX power limit support to 114 and 130 channels
From: Ping-Ke Shih @ 2026-04-13 5:56 UTC (permalink / raw)
To: Thadeu Lima de Souza Cascardo
Cc: Kalle Valo, Yan-Hsuan Chuang, linux-wireless@vger.kernel.org,
kernel-dev@igalia.com
In-Reply-To: <adjN1Tl1N_xpzBHd@quatroqueijos.cascardo.eti.br>
Thadeu Lima de Souza Cascardo <cascardo@igalia.com> wrote:
> On Fri, Apr 10, 2026 at 03:56:11AM +0000, Ping-Ke Shih wrote:
> > Thadeu Lima de Souza Cascardo <cascardo@igalia.com> wrote:
> > > Though 114 and 130 are not usual channels, they are found in the wild with
> > > setups using 5350MHz as the center frequency of a 80MHz setup.
> >
> > What did the AP setup? channel 114 160MHz?
> > I wonder why rtw88 can select a not usual channel 114 80MHz.
> >
> > Please share your environment setup.
> >
>
> This is a Mikrotik that uses channel 130 at 80MHz.
I'm surprised that an AP can work on this not usual channel/bandwidth.
Can you change the setting to usual channel/bandwidth? We'd avoid using
this unsupported channel/bandwidth by [1].
>
> > >
> > > rtw88 supports that, but issues a WARNING because it cannot find the TX
> > > power limit for those channels.
> >
> > Actually, rtw88 hardware can't support that, so we are working on patch
> > to avoid selecting unusual channels. Can it work properly with
> > the AP after this patch?
> >
>
> It does work just fine even without the patch. The only issue is the
> WARNING that is triggered.
>
As internal discussion, hardware doesn't work on channel 130 80M,
which means connection might be well, but it can't yield expected performance.
More, the power limit is not really verified on ch130 80M, so we wonder
that the signal might not in expectation.
By above reasons, we'd avoid using channel 114 and 130.
[1] https://lore.kernel.org/linux-wireless/20260413053601.13037-1-pkshih@realtek.com/T/#u
^ permalink raw reply
* Re: [patch 28/38] mips: Select ARCH_HAS_RANDOM_ENTROPY
From: Maciej W. Rozycki @ 2026-04-13 5:47 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Arnd Bergmann, x86, Lu Baolu, iommu, Michael Grzeschik,
netdev, linux-wireless, Herbert Xu, linux-crypto, Vlastimil Babka,
linux-mm, David Woodhouse, Bernie Thompson, linux-fbdev,
Theodore Tso, linux-ext4, Andrew Morton, Uladzislau Rezki,
Marco Elver, Dmitry Vyukov, kasan-dev, Andrey Ryabinin,
Thomas Sailer, linux-hams, Jason A. Donenfeld, Richard Henderson,
linux-alpha, Russell King, linux-arm-kernel, Catalin Marinas,
Huacai Chen, loongarch, Geert Uytterhoeven, linux-m68k,
Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.462206386@kernel.org>
On Fri, 10 Apr 2026, Thomas Gleixner wrote:
> The only solution for now is to uninline random_get_entropy(). Fix up all
> other dependencies on the content of asm/timex.h in those files which
> really depend on it.
Oh dear! I'd yet have to fully evaluate the consequences, but offhand
this has clearly turned what compiles to a single CPU instruction on the
vast majority of MIPS platforms into an expensive function call, possibly
also changing the caller from a leaf to a nested function with all the
associated execution penalty. Is there no other way?
Cf. commit 06947aaaf9bf ("MIPS: Implement random_get_entropy with CP0
Random").
Maciej
^ permalink raw reply
* [RFT rtw/rtw-next] wifi: rtw88: check if center channel is supported before setting
From: Ping-Ke Shih @ 2026-04-13 5:36 UTC (permalink / raw)
To: linux-wireless; +Cc: kevin_yang
From: Zong-Zhe Yang <kevin_yang@realtek.com>
Some unusual center channels may be assigned to driver. However, RF
doesn't really expect them, and then warnings happen due to lack of
TX power limit configurations. For example, center channel 114/130
with 80MHz. So, add a check before setting the channel.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
---
drivers/net/wireless/realtek/rtw88/mac80211.c | 7 +++++--
drivers/net/wireless/realtek/rtw88/main.c | 13 +++++++++++--
drivers/net/wireless/realtek/rtw88/main.h | 2 +-
drivers/net/wireless/realtek/rtw88/phy.c | 18 ++++++++++++++++++
drivers/net/wireless/realtek/rtw88/phy.h | 2 ++
5 files changed, 37 insertions(+), 5 deletions(-)
diff --git a/drivers/net/wireless/realtek/rtw88/mac80211.c b/drivers/net/wireless/realtek/rtw88/mac80211.c
index 766f22d31079..9d97e8dd0c1e 100644
--- a/drivers/net/wireless/realtek/rtw88/mac80211.c
+++ b/drivers/net/wireless/realtek/rtw88/mac80211.c
@@ -92,8 +92,11 @@ static int rtw_ops_config(struct ieee80211_hw *hw, int radio_idx, u32 changed)
}
}
- if (changed & IEEE80211_CONF_CHANGE_CHANNEL)
- rtw_set_channel(rtwdev);
+ if (changed & IEEE80211_CONF_CHANGE_CHANNEL) {
+ ret = rtw_set_channel(rtwdev);
+ if (ret)
+ goto out;
+ }
if ((changed & IEEE80211_CONF_CHANGE_IDLE) &&
(hw->conf.flags & IEEE80211_CONF_IDLE) &&
diff --git a/drivers/net/wireless/realtek/rtw88/main.c b/drivers/net/wireless/realtek/rtw88/main.c
index cd9254370fcc..08aebb3c5a78 100644
--- a/drivers/net/wireless/realtek/rtw88/main.c
+++ b/drivers/net/wireless/realtek/rtw88/main.c
@@ -868,23 +868,30 @@ void rtw_get_channel_params(struct cfg80211_chan_def *chandef,
chan_params->primary_chan = channel->hw_value;
}
-void rtw_set_channel(struct rtw_dev *rtwdev)
+int rtw_set_channel(struct rtw_dev *rtwdev)
{
const struct rtw_chip_info *chip = rtwdev->chip;
struct ieee80211_hw *hw = rtwdev->hw;
struct rtw_hal *hal = &rtwdev->hal;
struct rtw_channel_params ch_param;
u8 center_chan, primary_chan, bandwidth, band;
+ int ch_idx;
rtw_get_channel_params(&hw->conf.chandef, &ch_param);
if (WARN(ch_param.center_chan == 0, "Invalid channel\n"))
- return;
+ return -EINVAL;
center_chan = ch_param.center_chan;
primary_chan = ch_param.primary_chan;
bandwidth = ch_param.bandwidth;
band = ch_param.center_chan > 14 ? RTW_BAND_5G : RTW_BAND_2G;
+ ch_idx = rtw_band_channel_to_idx(band, center_chan);
+ if (ch_idx < 0) {
+ rtw_warn(rtwdev, "not support band %d ch %d\n", band, center_chan);
+ return -EOPNOTSUPP;
+ }
+
rtw_update_channel(rtwdev, center_chan, primary_chan, band, bandwidth);
if (rtwdev->scan_info.op_chan)
@@ -910,6 +917,8 @@ void rtw_set_channel(struct rtw_dev *rtwdev)
*/
if (!test_bit(RTW_FLAG_SCANNING, rtwdev->flags))
rtwdev->need_rfk = true;
+
+ return 0;
}
void rtw_chip_prepare_tx(struct rtw_dev *rtwdev)
diff --git a/drivers/net/wireless/realtek/rtw88/main.h b/drivers/net/wireless/realtek/rtw88/main.h
index 9c0b746540b0..a368f1a4a003 100644
--- a/drivers/net/wireless/realtek/rtw88/main.h
+++ b/drivers/net/wireless/realtek/rtw88/main.h
@@ -2241,7 +2241,7 @@ bool ltecoex_reg_write(struct rtw_dev *rtwdev, u16 offset, u32 value);
void rtw_restore_reg(struct rtw_dev *rtwdev,
struct rtw_backup_info *bckp, u32 num);
void rtw_desc_to_mcsrate(u16 rate, u8 *mcs, u8 *nss);
-void rtw_set_channel(struct rtw_dev *rtwdev);
+int rtw_set_channel(struct rtw_dev *rtwdev);
void rtw_chip_prepare_tx(struct rtw_dev *rtwdev);
void rtw_vif_port_config(struct rtw_dev *rtwdev, struct rtw_vif *rtwvif,
u32 config);
diff --git a/drivers/net/wireless/realtek/rtw88/phy.c b/drivers/net/wireless/realtek/rtw88/phy.c
index e2ac5c6fd500..a543eaa57f2c 100644
--- a/drivers/net/wireless/realtek/rtw88/phy.c
+++ b/drivers/net/wireless/realtek/rtw88/phy.c
@@ -1630,6 +1630,24 @@ static int rtw_channel_to_idx(u8 band, u8 channel)
return ch_idx;
}
+int rtw_band_channel_to_idx(enum rtw_supported_band band, u8 channel)
+{
+ u8 phy_band;
+
+ switch (band) {
+ case RTW_BAND_2G:
+ phy_band = PHY_BAND_2G;
+ break;
+ case RTW_BAND_5G:
+ phy_band = PHY_BAND_5G;
+ break;
+ default:
+ return -1;
+ }
+
+ return rtw_channel_to_idx(phy_band, channel);
+}
+
static void rtw_phy_set_tx_power_limit(struct rtw_dev *rtwdev, u8 regd, u8 band,
u8 bw, u8 rs, u8 ch, s8 pwr_limit)
{
diff --git a/drivers/net/wireless/realtek/rtw88/phy.h b/drivers/net/wireless/realtek/rtw88/phy.h
index 8449936497bb..98aeb576e24d 100644
--- a/drivers/net/wireless/realtek/rtw88/phy.h
+++ b/drivers/net/wireless/realtek/rtw88/phy.h
@@ -201,4 +201,6 @@ enum rtw_phy_cck_pd_lv {
#define RRSR_RATE_ORDER_MAX 0xfffff
#define RRSR_RATE_ORDER_CCK_LEN 4
+int rtw_band_channel_to_idx(enum rtw_supported_band band, u8 channel);
+
#endif
--
2.25.1
^ permalink raw reply related
* [PATCH 2/2] wifi: mt76: mt7915: validate skb length in txpower SKU query
From: Aviel Zohar @ 2026-04-13 3:31 UTC (permalink / raw)
To: linux-wireless
Cc: linux-mediatek, nbd, lorenzo, sean.wang, ryder.lee, Aviel Zohar
In-Reply-To: <20260413033136.5417-1-avielzohar123@gmail.com>
In mt7915_mcu_get_txpower_sku(), the response skb from
mt76_mcu_send_and_get_msg() is used in memcpy without validating
its length:
For TX_POWER_INFO_RATE:
memcpy(res, skb->data + 4, sizeof(res));
where sizeof(res) is MT7915_SKU_RATE_NUM * 2 = 322 bytes.
For TX_POWER_INFO_PATH:
memcpy(txpower, skb->data + 4, len);
In both cases, if the firmware returns a response shorter than
the expected size, the memcpy reads beyond the skb data buffer.
The data surfaces to userspace via debugfs (txpower_sku and
txpower_path).
Add length checks for both code paths before the memcpy.
Signed-off-by: Aviel Zohar <avielzohar123@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 8 ++++++++
1 file changed, 8 insertions(+)
--- a/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7915/mcu.c
@@ -3532,10 +3532,18 @@
if (category == TX_POWER_INFO_RATE) {
s8 res[MT7915_SKU_RATE_NUM][2];
+ if (skb->len < sizeof(res) + 4) {
+ dev_kfree_skb(skb);
+ return -EINVAL;
+ }
memcpy(res, skb->data + 4, sizeof(res));
for (i = 0; i < len; i++)
txpower[i] = res[i][req.band_idx];
} else if (category == TX_POWER_INFO_PATH) {
+ if (skb->len < len + 4) {
+ dev_kfree_skb(skb);
+ return -EINVAL;
+ }
memcpy(txpower, skb->data + 4, len);
}
^ permalink raw reply
* [PATCH 1/2] wifi: mt76: mt7925: validate skb length in testmode query
From: Aviel Zohar @ 2026-04-13 3:31 UTC (permalink / raw)
To: linux-wireless
Cc: linux-mediatek, nbd, lorenzo, sean.wang, ryder.lee, Aviel Zohar
In-Reply-To: <20260413033136.5417-1-avielzohar123@gmail.com>
In mt7925_tm_query(), the response skb from mt76_mcu_send_and_get_msg()
is used in a memcpy without validating its length:
memcpy(evt_resp, skb->data + 8, MT7925_EVT_RSP_LEN);
where MT7925_EVT_RSP_LEN is 512. If the firmware returns a response
shorter than 520 bytes (8 + 512), this reads beyond the skb data
buffer. The over-read data is then returned to userspace via nla_put()
in mt7925_testmode_dump().
Add a length check before the memcpy to ensure the skb contains
sufficient data.
Fixes: c948b5da6bbe ("wifi: mt76: mt7925: add Mediatek Wi-Fi7 driver for mt7925 chips")
Signed-off-by: Aviel Zohar <avielzohar123@gmail.com>
---
drivers/net/wireless/mediatek/mt76/mt7925/testmode.c | 5 +++++
1 file changed, 5 insertions(+)
--- a/drivers/net/wireless/mediatek/mt76/mt7925/testmode.c
+++ b/drivers/net/wireless/mediatek/mt76/mt7925/testmode.c
@@ -105,6 +105,11 @@
if (ret)
goto out;
+ if (skb->len < MT7925_EVT_RSP_LEN + 8) {
+ ret = -EINVAL;
+ goto out;
+ }
+
memcpy((char *)evt_resp, (char *)skb->data + 8, MT7925_EVT_RSP_LEN);
out:
^ permalink raw reply
* [PATCH 0/2] wifi: mt76: add missing skb length validation
From: Aviel Zohar @ 2026-04-13 3:31 UTC (permalink / raw)
To: linux-wireless
Cc: linux-mediatek, nbd, lorenzo, sean.wang, ryder.lee, Aviel Zohar
This series addresses missing skb length validation in two mt76
drivers before memcpy operations on firmware MCU responses.
In both cases, the driver copies a fixed number of bytes from
skb->data without first checking that skb->len is large enough.
If the firmware returns a shorter-than-expected response (due to a
bug, partial DMA transfer, or in the case of mt7925, a malicious
USB device), the memcpy reads beyond the skb data buffer, causing
a heap buffer over-read. The over-read data is subsequently
returned to userspace.
Patch 1: mt7925 testmode - mt7925_tm_query() copies 512 bytes
(MT7925_EVT_RSP_LEN) from skb->data + 8 without verifying
skb->len >= 520. The leaked data is returned via nla_put()
through nl80211 testmode dump. Fix adds a length check before
the memcpy.
Patch 2: mt7915 txpower - mt7915_mcu_get_txpower_sku() copies
up to 322 bytes (MT7915_SKU_RATE_NUM * 2) from skb->data + 4
without verifying skb->len. The data surfaces through debugfs
(txpower_sku, txpower_path). Fix adds length checks for both
the TX_POWER_INFO_RATE and TX_POWER_INFO_PATH code paths.
Both fixes follow the same pattern: validate skb->len before
performing the memcpy, returning -EINVAL on insufficient data.
Tested by code inspection; I do not have the hardware to
run-test these changes.
Aviel Zohar (2):
wifi: mt76: mt7925: validate skb length in testmode query
wifi: mt76: mt7915: validate skb length in txpower SKU query
drivers/net/wireless/mediatek/mt76/mt7925/testmode.c | 5 +++++
drivers/net/wireless/mediatek/mt76/mt7915/mcu.c | 8 ++++++++
2 files changed, 13 insertions(+)
--
2.34.1
^ permalink raw reply
* Re: [PATCH v3] wifi: iwlwifi: prevent NAPI processing after firmware error
From: Cole Leavitt @ 2026-04-13 2:09 UTC (permalink / raw)
To: Ben Greear, johannes.berg, miriam.rachel.korenblit; +Cc: linux-wireless, stable
In-Reply-To: <e6d6d4ad-475a-7bad-0dc9-6a920ed7f8ed@candelatech.com>
[-- Attachment #1.1: Type: text/plain, Size: 35493 bytes --]
Ben,
Thanks for the confirmation and the detailed logs. The Feb 26 trace is
exactly the scenario we designed the check for -- SYSTEM_STATISTICS_CMD
times out, driver forces NMI, and ksoftirqd/3 hits our WARN in
iwl_pcie_napi_poll_msix while the error dump is still printing. Good to
see it catching the race in production.
I owe you a correction on the TSO patch (2/3). You were right that my
commit message overclaimed causation between the 32k segment explosion
and the TCP UAF. I've been digging deeper into your Feb 16 crash trace
and here's what I've found I think:
The refcount underflow in tcp_shifted_skb is NOT a use-after-free.
I looked at your free_status debugging (commit 3b5f7046f in your tree)
and the fact that none of your checks fire means the skb is still
validly allocated when the underflow happens. The refcount that
underflows is sk->sk_wmem_alloc (the socket's write memory accounting),
not skb->users or dataref.
The crash path is:
tcp_shifted_skb -> tcp_rtx_queue_unlink_and_free -> tcp_wmem_free_skb
-> __kfree_skb -> skb_release_head_state -> sock_wfree
-> __refcount_sub_and_test(len, &sk->sk_wmem_alloc) -> UNDERFLOW
Something is subtracting more from sk_wmem_alloc than was added. I
traced every charge/drain path:
Charges: skb_set_owner_w() at creation, tcp_transmit_skb:1601 at clone
Drains: sock_wfree() or tcp_wfree() at destructor time
I also verified:
- TCP clones before sending (tcp_output.c:1539), so the TSO
segmentation operates on the clone, not the retransmit original
- skb_clone sets destructor=NULL (skbuff.c:1625), tcp_transmit_skb
re-sets it with a fresh refcount_add -- balanced per-skb
- pskb_expand_head in mac80211 (tx.c:2016) does NOT modify truesize
on TCP-owned skbs because of the guard at skbuff.c:2367
- skb_shift truesize changes during SACK coalescing are
self-balancing across the source/target pair
I've exhausted what I can find from code analysis alone. The accounting
mismatch is real but I can't identify the exact path without tracing
on the hardware.
I wrote a small debug patch that adds trace_printk at every
sk_wmem_alloc modification point:
- skb_set_owner_w(): charge at creation
- tcp_transmit_skb(): charge at clone
- sock_wfree(): drain (generic)
- tcp_wfree(): drain (TCP fast path)
- skb_shift(): truesize change during SACK coalescing
Could you apply the attached patch, reproduce against the problem AP,
and send me the ftrace output? The skb pointer in each trace line lets
us correlate exactly which charge/drain pair is imbalanced.
echo 1 > /sys/kernel/debug/tracing/tracing_on
# reproduce
cat /sys/kernel/debug/tracing/trace > /tmp/wmem_trace.txt
The trace will be noisy (every TCP packet), so grep for the socket
address from your crash (R12=ffff88820165f200 in your Feb 16 dump) to
filter to the relevant connection.
Separately, the TSO sentinel fix and the NAPI race fix are still correct
regardless of the TCP accounting issue. The sentinel value 1 producing
num_subframes=0 is a real bug -- I verified that only 7 code paths in
the entire kernel write max_tid_amsdu_len, and through legitimate MLD
code the only value that produces zero is the sentinel 1 from the TLC
notification. The WARN_ON_ONCE(!num_subframes) guard in the v2 patch
catches any corruption-induced zeros from unknown paths.
On your remaining 32k GSO spins after applying the sentinel fix: since
legitimate code can only produce values 0 (caught by existing check) or
1 (caught by our new check) or >= 2000 (safe), values 2-1533 that would
also produce num_subframes=0 can only come from memory corruption. Does
the WARN_ON_ONCE fire? If so, what max_tid_amsdu_len value does the
pr_warn_once in your tree (commit 9dd9677f5) print?
Cole
On 26/02/2026 12.37, Ben Greear wrote:
> On 2/14/26 10:43, Cole Leavitt wrote:
>> After a firmware error is detected and STATUS_FW_ERROR is set, NAPI can
>> still be actively polling or get scheduled from a prior interrupt. The
>> NAPI poll functions (both legacy and MSIX variants) have no check for
>> STATUS_FW_ERROR and will continue processing stale RX ring entries from
>> dying firmware. This can dispatch TX completion notifications containing
>> corrupt SSN values to iwl_mld_handle_tx_resp_notif(), which passes them
>> to iwl_trans_reclaim(). If the corrupt SSN causes reclaim to walk TX
>> queue entries that were already freed by a prior correct reclaim, the
>> result is an skb use-after-free or double-free.
>
> Hello Cole,
>
> We've been testing with this patch, and today managed to see its logic
> trigger.
> The system had a cascade of other errors leading to use-after-free
> that does
> not appear to be related to the skb use-after free, but I can at least
> confirm your
> patch can be triggered. Here are logs around this. I believe in this
> case, firmware
> didn't actually bubble up a crash notification/interrupt, but probably
> the driver detected timeout
> and faked a crash.
>
> Feb 26 11:09:35 ct523c-de7c kernel: workqueue: blk_mq_requeue_work
> hogged CPU for >10000us 4 times, consider switching to WQ_UNBOUND
> Feb 26 11:09:36 ct523c-de7c kernel: workqueue: gc_worker
> [nf_conntrack] hogged CPU for >10000us 515 times, consider switching
> to WQ_UNBOUND
> Feb 26 11:09:39 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Error
> sending SYSTEM_STATISTICS_CMD: time out after 2000ms.
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Current CMD
> queue read_ptr 92 write_ptr 93
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Start IWL
> Error Log Dump:
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Transport
> status: 0x0000004A, valid: 6
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Loaded
> firmware version: 101.6ef20b19.0 gl-c0-fm-c0-101.ucode
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000084 |
> NMI_INTERRUPT_UNKNOWN
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000002F0 |
> trm_hw_status0
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> trm_hw_status1
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x002C438C |
> branchlink2
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00009C04 |
> interruptlink1
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00009C04 |
> interruptlink2
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00009C3C |
> data1
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x01000000 |
> data2
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> data3
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xD040FE38 |
> beacon time
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x3B6411CD |
> tsf low
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000026B |
> tsf hi
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> time gp1
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0616DB18 |
> time gp2
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000001 |
> uCode revision type
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000065 |
> uCode version major
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x6EF20B19 |
> uCode version minor
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000472 |
> hw version
> Feb 26 11:09:40 ct523c-de7c kernel: ------------[ cut here ]------------
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi: NAPI MSIX poll[0] invoked
> after FW error
> Feb 26 11:09:40 ct523c-de7c kernel: WARNING: CPU: 3 PID: 36 at
> drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c:1058
> iwl_pcie_napi_poll_msix+0x29e/0x310 [iwlwifi]
> Feb 26 11:09:40 ct523c-de7c kernel: Modules linked in: vrf
> nf_conntrack_netlink nf_conntrack nfnetlink nf_defrag_ipv6
> nf_defrag_ipv4 8021q garp mrp stp llc macvlan pktgen rfcomm rpcrdma
> rdma_cm iw_cm ib_cm ib_core qrtr bnep intel_rapl_msr iTCO_wdt
> intel_pmc_bxt ee1004 iTCO_vendor_support iwlmld coretemp
> intel_rapl_common intel_uncore_frequency intel_uncore_frequency_common
> snd_hda_codec_intelhdmi snd_hda_codec_hdmi intel_tcc_cooling
> x86_pkg_temp_thermal snd_hda_codec_alc662 snd_hda_codec_realtek_lib
> intel_powerclamp intel_wmi_thunderbolt snd_hda_codec_generic
> snd_hda_intel snd_intel_dspcfg snd_hda_codec mac80211 snd_hda_core
> snd_hwdep snd_seq btusb btbcm snd_seq_device btmtk btrtl btintel
> snd_pcm iwlwifi bluetooth snd_timer cfg80211 i2c_i801 snd i2c_smbus
> soundcore i2c_mux mei_pxp mei_hdcp intel_pch_thermal intel_pmc_core
> pmt_telemetry pmt_discovery pmt_class intel_pmc_ssram_telemetry
> intel_vsec acpi_pad bfq nfsd sch_fq_codel auth_rpcgss nfs_acl lockd
> grace nfs_localio fuse sunrpc raid1 dm_raid raid456 async_raid6_recov
> async_memcpy async_pq
> Feb 26 11:09:40 ct523c-de7c kernel: async_xor xor async_tx raid6_pq
> i915 drm_buddy intel_gtt drm_client_lib drm_display_helper
> drm_kms_helper cec rc_core ttm agpgart ixgbe mdio igb libie_fwlog
> i2c_algo_bit dca drm hwmon mei_wdt i2c_core intel_oc_wdt video wmi
> scsi_dh_rdac scsi_dh_emc scsi_dh_alua dm_multipath [last unloaded:
> nfnetlink]
> Feb 26 11:09:40 ct523c-de7c kernel: CPU: 3 UID: 0 PID: 36 Comm:
> ksoftirqd/3 Kdump: loaded Not tainted 6.18.9+ #18 PREEMPT(full)
> Feb 26 11:09:40 ct523c-de7c kernel: Hardware name: Default string
> Default string/SKYBAY, BIOS 5.12 02/21/2023
> Feb 26 11:09:40 ct523c-de7c kernel: RIP:
> 0010:iwl_pcie_napi_poll_msix+0x29e/0x310 [iwlwifi]
> Feb 26 11:09:40 ct523c-de7c kernel: Code: 00 00 fc ff df 48 89 fa 48
> c1 ea 03 0f b6 04 02 84 c0 74 04 3c 03 7e 74 8b b3 48 ff ff ff 48 c7
> c7 a0 d2 19 a2 e8 62 00 0f df <0f> 0b eb 96 4c 89 e7 e8 d6 92 9f df e9
> 0b fe ff ff e8 cc 92 9f df
> Feb 26 11:09:40 ct523c-de7c kernel: RSP: 0018:ffff888120fe7b70 EFLAGS:
> 00010286
> Feb 26 11:09:40 ct523c-de7c kernel: RAX: 0000000000000000 RBX:
> ffff888182e100b8 RCX: 0000000000000001
> Feb 26 11:09:40 ct523c-de7c kernel: RDX: 0000000000000027 RSI:
> 0000000000000004 RDI: ffff88841dba4e48
> Feb 26 11:09:40 ct523c-de7c kernel: RBP: ffff888132504028 R08:
> 0000000000000001 R09: ffffed1083b749c9
> Feb 26 11:09:40 ct523c-de7c kernel: R10: ffff88841dba4e4b R11:
> 0000000000072ee8 R12: ffff888132504090
> Feb 26 11:09:40 ct523c-de7c kernel: R13: ffff888132504d90 R14:
> 0000000000000040 R15: ffff888134b480b8
> Feb 26 11:09:40 ct523c-de7c kernel: FS: 0000000000000000(0000)
> GS:ffff8884974c7000(0000) knlGS:0000000000000000
> Feb 26 11:09:40 ct523c-de7c kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
> 0000000080050033
> Feb 26 11:09:40 ct523c-de7c kernel: CR2: 00007fd5beb80028 CR3:
> 000000013e2d4001 CR4: 00000000003706f0
> Feb 26 11:09:40 ct523c-de7c kernel: Call Trace:
> Feb 26 11:09:40 ct523c-de7c kernel: <TASK>
> Feb 26 11:09:40 ct523c-de7c kernel: __napi_poll.constprop.0+0xa0/0x580
> Feb 26 11:09:40 ct523c-de7c kernel: net_rx_action+0x84d/0xe40
> Feb 26 11:09:40 ct523c-de7c kernel: ?
> __napi_poll.constprop.0+0x580/0x580
> Feb 26 11:09:40 ct523c-de7c kernel: ? do_raw_spin_lock+0x12c/0x270
> Feb 26 11:09:40 ct523c-de7c kernel: ? run_timer_softirq+0xf2/0x1b0
> Feb 26 11:09:40 ct523c-de7c kernel: ? lock_release+0xce/0x290
> Feb 26 11:09:40 ct523c-de7c kernel: ?
> trace_irq_enable.constprop.0+0xbe/0x100
> Feb 26 11:09:40 ct523c-de7c kernel: handle_softirqs+0x1c6/0x810
> Feb 26 11:09:40 ct523c-de7c kernel: run_ksoftirqd+0x2d/0x50
> Feb 26 11:09:40 ct523c-de7c kernel: smpboot_thread_fn+0x338/0x8c0
> Feb 26 11:09:40 ct523c-de7c kernel: ? sort_range+0x20/0x20
> Feb 26 11:09:40 ct523c-de7c kernel: kthread+0x3b7/0x770
> Feb 26 11:09:40 ct523c-de7c kernel: ? kthread_is_per_cpu+0xb0/0xb0
> Feb 26 11:09:40 ct523c-de7c kernel: ? ret_from_fork+0x17/0x3a0
> Feb 26 11:09:40 ct523c-de7c kernel: ? lock_release+0xce/0x290
> Feb 26 11:09:40 ct523c-de7c kernel: ? kthread_is_per_cpu+0xb0/0xb0
> Feb 26 11:09:40 ct523c-de7c kernel: ret_from_fork+0x28b/0x3a0
> Feb 26 11:09:40 ct523c-de7c kernel: ? kthread_is_per_cpu+0xb0/0xb0
> Feb 26 11:09:40 ct523c-de7c kernel: ret_from_fork_asm+0x11/0x20
> Feb 26 11:09:40 ct523c-de7c kernel: </TASK>
> Feb 26 11:09:40 ct523c-de7c kernel: irq event stamp: 36429934
> Feb 26 11:09:40 ct523c-de7c kernel: hardirqs last enabled at
> (36429940): [<ffffffff816116ee>] __up_console_sem+0x5e/0x70
> Feb 26 11:09:40 ct523c-de7c kernel: hardirqs last disabled at
> (36429945): [<ffffffff816116d3>] __up_console_sem+0x43/0x70
> Feb 26 11:09:40 ct523c-de7c kernel: softirqs last enabled at
> (36428910): [<ffffffff81471d3d>] run_ksoftirqd+0x2d/0x50
> Feb 26 11:09:40 ct523c-de7c kernel: softirqs last disabled at
> (36428915): [<ffffffff81471d3d>] run_ksoftirqd+0x2d/0x50
> Feb 26 11:09:40 ct523c-de7c kernel: ---[ end trace 0000000000000000 ]---
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00C80002 |
> board version
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x036D001C |
> hcmd
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xF6F38000 |
> isr0
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x01400000 |
> isr1
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x48F00002 |
> isr2
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00C00008 |
> isr3
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x18200000 |
> isr4
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x036D001C |
> last cmd Id
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00009C3C |
> wait_event
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x10000010 |
> l2p_control
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> l2p_duration
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> l2p_mhvalid
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> l2p_addr_match
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000009 |
> lmpm_pmg_sel
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> timestamp
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00009018 |
> flow_handler
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Start IWL
> Error Log Dump:
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Transport
> status: 0x0000004A, valid: 6
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Loaded
> firmware version: 101.6ef20b19.0 gl-c0-fm-c0-101.ucode
> Feb 26 11:09:40 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000084 |
> NMI_INTERRUPT_UNKNOWN
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000002F0 |
> trm_hw_status0
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> trm_hw_status1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x002C438C |
> branchlink2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x002B8AD0 |
> interruptlink1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x002B8AD0 |
> interruptlink2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x002A5822 |
> data1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x01000000 |
> data2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> data3
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xD040FE37 |
> beacon time
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x3B6411CE |
> tsf low
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000026B |
> tsf hi
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> time gp1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0616DB19 |
> time gp2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000001 |
> uCode revision type
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000065 |
> uCode version major
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x6EF20B19 |
> uCode version minor
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000472 |
> hw version
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00C80002 |
> board version
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x804AFC12 |
> hcmd
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00020000 |
> isr0
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> isr1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x48F00002 |
> isr2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00C0001C |
> isr3
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> isr4
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> last cmd Id
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x002A5822 |
> wait_event
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x10000010 |
> l2p_control
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> l2p_duration
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> l2p_mhvalid
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> l2p_addr_match
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000028 |
> lmpm_pmg_sel
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> timestamp
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00009018 |
> flow_handler
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Start IWL
> Error Log Dump:
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Transport
> status: 0x0000004A, valid: 7
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x20000066 |
> NMI_INTERRUPT_HOST
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> umac branchlink1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xC00808AA |
> umac branchlink2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x80287BFE |
> umac interruptlink1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0102163E |
> umac interruptlink2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x01000000 |
> umac data1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0102163E |
> umac data2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> umac data3
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000065 |
> umac major
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x6EF20B19 |
> umac minor
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0616DB0F |
> frame pointer
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xD00D6258 |
> stack pointer
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x005C020F |
> last host cmd
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000400 |
> isr status reg
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: TCM1 status:
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000070 |
> error ID
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00001D2E |
> tcm branchlink2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000211C |
> tcm interruptlink1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000211C |
> tcm interruptlink2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x40000000 |
> tcm data1
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xDEADBEEF |
> tcm data2
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xDEADBEEF |
> tcm data3
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00001DAC |
> tcm log PC
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00803FF0 |
> tcm frame pointer
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00803F5C |
> tcm stack pointer
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm msg ID
> Feb 26 11:09:41 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x4000001F |
> tcm ISR status
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000002F0 |
> tcm HW status[0]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm HW status[1]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm HW status[2]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x40008300 |
> tcm HW status[3]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm HW status[4]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm SW status[0]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: RCM1 status:
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000070 |
> error ID
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00001E2E |
> rcm branchlink2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000027A0 |
> rcm interruptlink1
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000027A0 |
> rcm interruptlink2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x20000000 |
> rcm data1
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xDEADBEEF |
> rcm data2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xDEADBEEF |
> rcm data3
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00001E98 |
> rcm log PC
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00803FF0 |
> rcm frame pointer
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00803F5C |
> rcm stack pointer
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> rcm msg ID
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x2006F000 |
> rcm ISR status
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00020400 |
> frame HW status
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> LMAC-to-RCM request mbox
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> RCM-to-LMAC request mbox
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> MAC header control
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> MAC header addr1 low
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x003C0000 |
> MAC header info
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> MAC header error
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: TCM2 status:
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000070 |
> error ID
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00001D2E |
> tcm branchlink2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000211C |
> tcm interruptlink1
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000211C |
> tcm interruptlink2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x40000000 |
> tcm data1
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xDEADBEEF |
> tcm data2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xDEADBEEF |
> tcm data3
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00001DAC |
> tcm log PC
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00803FF0 |
> tcm frame pointer
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00803F5C |
> tcm stack pointer
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm msg ID
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x60000000 |
> tcm ISR status
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000002F0 |
> tcm HW status[0]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm HW status[1]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm HW status[2]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00008000 |
> tcm HW status[3]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm HW status[4]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> tcm SW status[0]
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: RCM2 status:
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000070 |
> error ID
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00001E2E |
> rcm branchlink2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000027A0 |
> rcm interruptlink1
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000027A0 |
> rcm interruptlink2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x20000000 |
> rcm data1
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xDEADBEEF |
> rcm data2
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0xDEADBEEF |
> rcm data3
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00001E98 |
> rcm log PC
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00803FF0 |
> rcm frame pointer
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00803F5C |
> rcm stack pointer
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> rcm msg ID
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x20000000 |
> rcm ISR status
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00020400 |
> frame HW status
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> LMAC-to-RCM request mbox
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> RCM-to-LMAC request mbox
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> MAC header control
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> MAC header addr1 low
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x003C0000 |
> MAC header info
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> MAC header error
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: IML/ROM dump:
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000B03 |
> IML/ROM error/state
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000EEE3 |
> IML/ROM data1
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000080 |
> IML/ROM WFPM_AUTH_KEY_0
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Fseq Registers:
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x60000000 |
> FSEQ_ERROR_CODE
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x80B10006 |
> FSEQ_TOP_INIT_VERSION
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00570000 |
> FSEQ_CNVIO_INIT_VERSION
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000AA14 |
> FSEQ_OTP_VERSION
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x0000000F |
> FSEQ_TOP_CONTENT_VERSION
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x4552414E |
> FSEQ_ALIVE_TOKEN
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x02001910 |
> FSEQ_CNVI_ID
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x02001910 |
> FSEQ_CNVR_ID
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x02001910 |
> CNVI_AUX_MISC_CHIP
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x02001910 |
> CNVR_AUX_MISC_CHIP
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x8F0F1BEF |
> CNVR_SCU_SD_REGS_SD_REG_DIG_DCDC_VTRIM
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00000000 |
> CNVR_SCU_SD_REGS_SD_REG_ACTIVE_VDIG_MIRROR
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00570000 |
> FSEQ_PREV_CNVIO_INIT_VERSION
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00B10006 |
> FSEQ_WIFI_FSEQ_VERSION
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x00B10005 |
> FSEQ_BT_FSEQ_VERSION
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x000000DC |
> FSEQ_CLASS_TP_VERSION
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: UMAC CURRENT
> PC: 0x8028b720
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: LMAC1
> CURRENT PC: 0xd0
> Feb 26 11:09:42 ct523c-de7c kernel: iwlwifi 0000:28:00.0: LMAC2
> CURRENT PC: 0xd0
> Feb 26 11:09:43 ct523c-de7c kernel: iwlwifi 0000:28:00.0: UMAC CURRENT
> PC 1: 0x8028b722
> Feb 26 11:09:43 ct523c-de7c kernel: iwlwifi 0000:28:00.0: TCM1 CURRENT
> PC: 0xd0
> Feb 26 11:09:43 ct523c-de7c kernel: iwlwifi 0000:28:00.0: RCM1 CURRENT
> PC: 0xd0
> Feb 26 11:09:43 ct523c-de7c kernel: iwlwifi 0000:28:00.0: RCM2 CURRENT
> PC: 0xd0
> Feb 26 11:09:43 ct523c-de7c kernel: iwlwifi 0000:28:00.0: Function
> Scratch status:
> Feb 26 11:09:43 ct523c-de7c kernel: iwlwifi 0000:28:00.0: 0x01010100 |
> Func Scratch
> Feb 26 11:09:43 ct523c-de7c kernel: iwlwifi 0000:28:00.0: WRT:
> Collecting data: ini trigger 4 fired (delay=0ms).
>
>
> Thanks,
> Ben
>
>>
>> The race window opens when the MSIX IRQ handler schedules NAPI (lines
>> 2319-2321 in rx.c) before processing the error bit (lines 2382-2396),
>> or when NAPI is already running on another CPU from a previous interrupt
>> when STATUS_FW_ERROR gets set on the current CPU.
>>
>> Add STATUS_FW_ERROR checks to both NAPI poll functions to prevent
>> processing stale RX data after firmware error, and add early-return
>> guards in the TX response and compressed BA notification handlers as
>> defense-in-depth. Each check uses WARN_ONCE to log if the race is
>> actually hit, which aids diagnosis of the hard-to-reproduce skb
>> use-after-free reported on Intel BE200.
>>
>> Note that _iwl_trans_pcie_gen2_stop_device() already calls
>> iwl_pcie_rx_napi_sync() to quiesce NAPI during device teardown, but that
>> runs much later in the restart sequence. These checks close the window
>> between error detection and device stop.
>>
>> Fixes: d1e879ec600f ("wifi: iwlwifi: add iwlmld sub-driver")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Cole Leavitt <cole@unwrap.rs>
>> ---
>> Changes since v1:
>> - Added Fixes: tag and Cc: stable@vger.kernel.org
>>
>> Tested on Intel BE200 (FW 101.6e695a70.0) by forcing NMI via debugfs.
>> The WARN_ONCE fires reliably:
>>
>> iwlwifi: NAPI MSIX poll[0] invoked after FW error
>> WARNING: drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c:1058
>> at iwl_pcie_napi_poll_msix+0xff/0x130 [iwlwifi], CPU#22
>>
>> Confirming NAPI poll is invoked after STATUS_FW_ERROR is set. Without
>> this patch, that poll processes stale RX ring data from dead firmware.
>>
>> drivers/net/wireless/intel/iwlwifi/mld/tx.c | 19 ++++++++++++++++++
>> .../wireless/intel/iwlwifi/pcie/gen1_2/rx.c | 20 +++++++++++++++++++
>> 2 files changed, 39 insertions(+)
>>
>> diff --git a/drivers/net/wireless/intel/iwlwifi/mld/tx.c
>> b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
>> index 3b4b575aadaa..3e99f3ded9bc 100644
>> --- a/drivers/net/wireless/intel/iwlwifi/mld/tx.c
>> +++ b/drivers/net/wireless/intel/iwlwifi/mld/tx.c
>> @@ -1071,6 +1071,18 @@ void iwl_mld_handle_tx_resp_notif(struct
>> iwl_mld *mld,
>> bool mgmt = false;
>> bool tx_failure = (status & TX_STATUS_MSK) != TX_STATUS_SUCCESS;
>> + /* Firmware is dead — the TX response may contain corrupt SSN
>> values
>> + * from a dying firmware DMA. Processing it could cause
>> + * iwl_trans_reclaim() to free the wrong TX queue entries,
>> leading to
>> + * skb use-after-free or double-free.
>> + */
>> + if (unlikely(test_bit(STATUS_FW_ERROR, &mld->trans->status))) {
>> + WARN_ONCE(1,
>> + "iwlwifi: TX resp notif (sta=%d txq=%d) after FW
>> error\n",
>> + sta_id, txq_id);
>> + return;
>> + }
>> +
>> if (IWL_FW_CHECK(mld, tx_resp->frame_count != 1,
>> "Invalid tx_resp notif frame_count (%d)\n",
>> tx_resp->frame_count))
>> @@ -1349,6 +1361,13 @@ void iwl_mld_handle_compressed_ba_notif(struct
>> iwl_mld *mld,
>> u8 sta_id = ba_res->sta_id;
>> struct ieee80211_link_sta *link_sta;
>> + if (unlikely(test_bit(STATUS_FW_ERROR, &mld->trans->status))) {
>> + WARN_ONCE(1,
>> + "iwlwifi: BA notif (sta=%d) after FW error\n",
>> + sta_id);
>> + return;
>> + }
>> +
>> if (!tfd_cnt)
>> return;
>> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
>> b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
>> index 619a9505e6d9..ba18d35fa55d 100644
>> --- a/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
>> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/gen1_2/rx.c
>> @@ -1015,6 +1015,18 @@ static int iwl_pcie_napi_poll(struct
>> napi_struct *napi, int budget)
>> trans_pcie = iwl_netdev_to_trans_pcie(napi->dev);
>> trans = trans_pcie->trans;
>> + /* Stop processing RX if firmware has crashed. Stale
>> notifications
>> + * from dying firmware (e.g. TX completions with corrupt SSN
>> values)
>> + * can cause use-after-free in reclaim paths.
>> + */
>> + if (unlikely(test_bit(STATUS_FW_ERROR, &trans->status))) {
>> + WARN_ONCE(1,
>> + "iwlwifi: NAPI poll[%d] invoked after FW error\n",
>> + rxq->id);
>> + napi_complete_done(napi, 0);
>> + return 0;
>> + }
>> +
>> ret = iwl_pcie_rx_handle(trans, rxq->id, budget);
>> IWL_DEBUG_ISR(trans, "[%d] handled %d, budget %d\n",
>> @@ -1042,6 +1054,14 @@ static int iwl_pcie_napi_poll_msix(struct
>> napi_struct *napi, int budget)
>> trans_pcie = iwl_netdev_to_trans_pcie(napi->dev);
>> trans = trans_pcie->trans;
>> + if (unlikely(test_bit(STATUS_FW_ERROR, &trans->status))) {
>> + WARN_ONCE(1,
>> + "iwlwifi: NAPI MSIX poll[%d] invoked after FW error\n",
>> + rxq->id);
>> + napi_complete_done(napi, 0);
>> + return 0;
>> + }
>> +
>> ret = iwl_pcie_rx_handle(trans, rxq->id, budget);
>> IWL_DEBUG_ISR(trans, "[%d] handled %d, budget %d\n", rxq->id, ret,
>> budget);
>
--
Email Signature
Cole Leavitt
Cole Leavitt
Principal Security Engineer
+1 (520) 870-0922 <tel:+15208700922>
4050 E COTTON CENTER BLVD STE 40
PHOENIX AZ 85040-8863
fiwealth.com <https://fiwealth.com>
Foundations Investment Advisors
Please consider the environment before printing this email.
*IMPORTANT NOTICE*
Foundations Investment Advisors, LLC is registered with the U.S.
Securities and Exchange Commission as an investment adviser pursuant to
the Investment Advisers Act of 1940, 15 U.S.C. § 80b. Registration does
not imply a certain level of skill or training. See Form ADV Part 2A,
Item 1.C at adviserinfo.sec.gov <https://adviserinfo.sec.gov>.
This email may contain confidential or privileged information protected
under Fed. R. Evid. 502. It is intended solely for the named addressee.
If received in error, notify the sender immediately and delete all
copies. Unauthorized review, copying, or distribution is prohibited.
[-- Attachment #1.2.1: Type: text/html, Size: 47036 bytes --]
[-- Attachment #1.2.2: uQTg7sS1jQmGBnc9.jpg --]
[-- Type: image/jpeg, Size: 173248 bytes --]
[-- Attachment #1.2.3: 1ftrbDu00oyei46w.png --]
[-- Type: image/png, Size: 19247 bytes --]
[-- Attachment #2: 0001-tcp-add-sk_wmem_alloc-tracing-for-debugging-refcount.patch --]
[-- Type: text/x-patch, Size: 3494 bytes --]
From 11e879ee063da6ba06b37e10d2bd36af794ef219 Mon Sep 17 00:00:00 2001
From: Cole Leavitt <cole@unwrap.rs>
Date: Sun, 12 Apr 2026 18:24:54 -0700
Subject: [PATCH] tcp: add sk_wmem_alloc tracing for debugging refcount
underflow
Add trace_printk instrumentation at every point that modifies
sk_wmem_alloc to diagnose a refcount underflow bug observed on
iwlwifi BE200 during TCP SACK processing.
Trace points added:
- skb_set_owner_w(): charge at skb creation
- tcp_transmit_skb(): charge at clone transmission
- sock_wfree(): drain at skb free (generic path)
- tcp_wfree(): drain at skb free (TCP fast path)
- skb_shift(): truesize modification during SACK coalescing
These trace_printk calls are for debugging only and should not
be merged upstream. Use ftrace to capture:
echo 1 > /sys/kernel/debug/tracing/tracing_on
<reproduce the crash>
cat /sys/kernel/debug/tracing/trace
NOT-FOR-UPSTREAM: debugging instrumentation
Signed-off-by: Cole Leavitt <cole@unwrap.rs>
---
net/core/skbuff.c | 1 +
net/core/sock.c | 2 ++
net/ipv4/tcp_output.c | 2 ++
3 files changed, 5 insertions(+)
diff --git a/net/core/skbuff.c b/net/core/skbuff.c
index 43ee86dcf2ea..dbf6a05839e4 100644
--- a/net/core/skbuff.c
+++ b/net/core/skbuff.c
@@ -4373,6 +4373,7 @@ int skb_shift(struct sk_buff *tgt, struct sk_buff *skb, int shiftlen)
tgt->ip_summed = CHECKSUM_PARTIAL;
skb->ip_summed = CHECKSUM_PARTIAL;
+ trace_printk("skb_shift: src=%px ts=%u dst=%px ts=%u shift=%d\n", skb, skb->truesize, tgt, tgt->truesize, shiftlen);
skb_len_add(skb, -shiftlen);
skb_len_add(tgt, shiftlen);
diff --git a/net/core/sock.c b/net/core/sock.c
index 5976100a9d55..c79bbebee322 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -2672,6 +2672,7 @@ void sock_wfree(struct sk_buff *skb)
bool free;
int old;
+ trace_printk("sock_wfree: -%u before=%d skb=%px\n", len, refcount_read(&sk->sk_wmem_alloc), skb);
if (!sock_flag(sk, SOCK_USE_WRITE_QUEUE)) {
if (sock_flag(sk, SOCK_RCU_FREE) &&
sk->sk_write_space == sock_def_write_space) {
@@ -2731,6 +2732,7 @@ void skb_set_owner_w(struct sk_buff *skb, struct sock *sk)
* all in-flight packets are completed
*/
__refcount_add(skb->truesize, &sk->sk_wmem_alloc, &old_wmem);
+ trace_printk("set_owner_w: +%u after=%d skb=%px\n", skb->truesize, old_wmem + (int)skb->truesize, skb);
/* (old_wmem == SK_WMEM_ALLOC_BIAS) if no other TX packet for this socket
* is in a host queue (qdisc, NIC queue).
diff --git a/net/ipv4/tcp_output.c b/net/ipv4/tcp_output.c
index 326b58ff1118..689deb63b1b2 100644
--- a/net/ipv4/tcp_output.c
+++ b/net/ipv4/tcp_output.c
@@ -1388,6 +1388,7 @@ void tcp_wfree(struct sk_buff *skb)
/* Keep one reference on sk_wmem_alloc.
* Will be released by sk_free() from here or tcp_tsq_workfn()
*/
+ trace_printk("tcp_wfree: -%u before=%d skb=%px\n", skb->truesize - 1, refcount_read(&sk->sk_wmem_alloc), skb);
WARN_ON(refcount_sub_and_test(skb->truesize - 1, &sk->sk_wmem_alloc));
/* If this softirq is serviced by ksoftirqd, we are likely under stress.
@@ -1599,6 +1600,7 @@ static int __tcp_transmit_skb(struct sock *sk, struct sk_buff *skb,
skb->sk = sk;
skb->destructor = skb_is_tcp_pure_ack(skb) ? __sock_wfree : tcp_wfree;
refcount_add(skb->truesize, &sk->sk_wmem_alloc);
+ trace_printk("tcp_xmit: +%u after=%d skb=%px\n", skb->truesize, refcount_read(&sk->sk_wmem_alloc), skb);
skb_set_dst_pending_confirm(skb, READ_ONCE(sk->sk_dst_pending_confirm));
--
2.52.0
^ permalink raw reply related
* Re: [PATCH net 1/4] nfc: digital: Fix stack buffer overflow in digital_in_recv_sensf_res()
From: Jakub Kicinski @ 2026-04-12 20:58 UTC (permalink / raw)
To: Lekë Hapçiu; +Cc: netdev, linux-wireless, stable, krzysztof.kozlowski
In-Reply-To: <20260409223436.1887988-2-snowwlake@icloud.com>
On Fri, 10 Apr 2026 00:34:31 +0200 Lekë Hapçiu wrote:
> The function digital_in_recv_sensf_res() validates that the incoming
> SENSF_RES frame is at least DIGITAL_SENSF_RES_MIN_LENGTH (17) bytes,
> but does not check that it is at most NFC_SENSF_RES_MAXSIZE (18) bytes
> before copying into the 18-byte target.sensf_res stack buffer.
Hm, third similar fix we received for this.
struct digital_sensf_res is 19 bytes, you're capping the length at 18
something else is wrong here..
^ permalink raw reply
* Re: [GIT PULL] wireless-next-2026-04-10
From: patchwork-bot+netdevbpf @ 2026-04-12 16:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: netdev, linux-wireless
In-Reply-To: <20260410064703.735099-3-johannes@sipsolutions.net>
Hello:
This pull request was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:
On Fri, 10 Apr 2026 08:44:33 +0200 you wrote:
> Hi,
>
> Final (obviously) pull request for now, the only thing to
> note is the crypto changes, FWIW the change touching crypto
> was acked by Herbert and he asked me to take it:
> https://lore.kernel.org/r/adYNVB3n358xm_s8@gondor.apana.org.au/
>
> [...]
Here is the summary with links:
- [GIT,PULL] wireless-next-2026-04-10
https://git.kernel.org/netdev/net-next/c/118cbd428e43
You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
^ permalink raw reply
* Re: [PATCH] mac80211_hwsim: change hwsim_class to a const struct
From: Jori Koolstra @ 2026-04-12 14:20 UTC (permalink / raw)
To: Johannes Berg; +Cc: Greg Kroah-Hartman, open list:MAC80211, open list
In-Reply-To: <538186550596da7b862eb7340047695267f8b71e.camel@sipsolutions.net>
> Op 07-04-2026 15:46 CEST schreef Johannes Berg <johannes@sipsolutions.net>:
>
>
> Hi,
>
> The subject should have a "wifi: " prefix. Maybe we need a MAINTAINERS
> thing for that ...
Sounds like a good idea... I am just guessing because with the cleanup work
I am not familiar with the conventions of each subsystem I am cleaning up in.
>
> Also, this patch doesn't apply on wireless-next, please respin.
>
I just saw that it has been already applied.
> johannes
Thanks,
Jori.
^ permalink raw reply
* Re: [PATCH 2/3] wifi: iwlwifi: mld: fix TSO segmentation explosion when AMSDU is disabled
From: Ben Greear @ 2026-04-12 14:03 UTC (permalink / raw)
To: Korenblit, Miriam Rachel, Cole Leavitt,
linux-wireless@vger.kernel.org
Cc: johannes@sipsolutions.net
In-Reply-To: <DS0PR11MB788029013A25A284B0907D01A3272@DS0PR11MB7880.namprd11.prod.outlook.com>
On 4/11/26 8:47 PM, Korenblit, Miriam Rachel wrote:
>
>
>> -----Original Message-----
>> From: Cole Leavitt <cole@unwrap.rs>
>> Sent: Sunday, April 5, 2026 8:42 AM
>> To: linux-wireless@vger.kernel.org
>> Cc: greearb@candelatech.com; Korenblit, Miriam Rachel
>> <miriam.rachel.korenblit@intel.com>; johannes@sipsolutions.net;
>> cole@unwrap.rs
>> Subject: [PATCH 2/3] wifi: iwlwifi: mld: fix TSO segmentation explosion when
>> AMSDU is disabled
>>
>> When the TLC notification disables AMSDU for a TID, the MLD driver sets
>> max_tid_amsdu_len to the sentinel value 1. The TSO segmentation path in
>> iwl_mld_tx_tso_segment() checks for zero but not for this sentinel, allowing it to
>> reach the num_subframes calculation:
>>
>> num_subframes = (max_tid_amsdu_len + pad) / (subf_len + pad)
>> = (1 + 2) / (1534 + 2) = 0
>>
>> This zero propagates to iwl_tx_tso_segment() which sets:
>>
>> gso_size = num_subframes * mss = 0
>>
>> Calling skb_gso_segment() with gso_size=0 creates over 32000 tiny segments
>> from a single GSO skb. This floods the TX ring with ~1024 micro-frames (the rest
>> are purged), creating a massive burst of TX completion events that can lead to
>> memory corruption and a subsequent use-after-free in TCP's retransmit queue
>> (refcount underflow in tcp_shifted_skb, NULL deref in tcp_rack_detect_loss).
>
> And why not fixing this issue?
We have been running with this patch. It doesn't seem to cause harm,
but also, we still saw at least a few warnings about 32k spins in GSO logic.
I am pretty sure the 32k GSO spin we see is due to some skb memory corruption of some kind,
and I don't know root cause.
Maybe this patch is still worth having, but the description about lots of tx completion events
causing mem corruption seems unfounded to me, and while I have no proof, this sort of
over-confidence in cause vs affect appears similar to some other AI generated patches I've seen.
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [patch 23/38] alpha: Select ARCH_HAS_RANDOM_ENTROPY
From: Magnus Lindholm @ 2026-04-12 13:22 UTC (permalink / raw)
To: Thomas Gleixner
Cc: LKML, Richard Henderson, linux-alpha, Arnd Bergmann, x86,
Lu Baolu, iommu, Michael Grzeschik, netdev, linux-wireless,
Herbert Xu, linux-crypto, Vlastimil Babka, linux-mm,
David Woodhouse, Bernie Thompson, linux-fbdev, Theodore Tso,
linux-ext4, Andrew Morton, Uladzislau Rezki, Marco Elver,
Dmitry Vyukov, kasan-dev, Andrey Ryabinin, Thomas Sailer,
linux-hams, Jason A. Donenfeld, Russell King, linux-arm-kernel,
Catalin Marinas, Huacai Chen, loongarch, Geert Uytterhoeven,
linux-m68k, Dinh Nguyen, Jonas Bonn, linux-openrisc, Helge Deller,
linux-parisc, Michael Ellerman, linuxppc-dev, Paul Walmsley,
linux-riscv, Heiko Carstens, linux-s390, David S. Miller,
sparclinux
In-Reply-To: <20260410120319.131582521@kernel.org>
On Fri, Apr 10, 2026 at 2:36 PM Thomas Gleixner <tglx@kernel.org> wrote:
>
> The only remaining usage of get_cycles() is to provide
> random_get_entropy().
>
> Switch alpha over to the new scheme of selecting ARCH_HAS_RANDOM_ENTROPY
> and providing random_get_entropy() in asm/random.h.
>
> Remove asm/timex.h as it has no functionality anymore.
>
> Signed-off-by: Thomas Gleixner <tglx@kernel.org>
> Cc: Richard Henderson <richard.henderson@linaro.org>
> Cc: linux-alpha@vger.kernel.org
> ---
> arch/alpha/Kconfig | 1 +
> arch/alpha/include/asm/random.h | 14 ++++++++++++++
> arch/alpha/include/asm/timex.h | 26 --------------------------
> 3 files changed, 15 insertions(+), 26 deletions(-)
Hi,
The Alpha side looks fine to me.
I've applied this patch on top of v7.0-rc7, built a kernel successfully,
boot-tested it on an Alpha UP2000+ (SMP) without issues.
Acked-by: Magnus Lindholm <linmag7@gmail.com>
Tested-by: Magnus Lindholm <linmag7@gmail.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox