* [PATCH v6 wireless] mac80211: fix NULL pointer dereference in monitor mode
From: Dhyan K Prajapati @ 2026-02-05 17:52 UTC (permalink / raw)
To: Greg KH
Cc: Johannes Berg, linux-wireless, netdev, stable, Dhyan K Prajapati,
Johannes Berg
Crash trace:
RIP: iwlagn_bss_info_changed+0x19d/0x640 [iwldvm]
Code: 49 8b 46 10 <8b> 10
RAX: 0000000000000000 (NULL link->conf->bss)
wifi: mac80211: fix NULL pointer deref regression in link notify
Commit c57e5b974514 ("wifi: mac80211: fix WARN_ON for monitor mode on
some devices") reorganized link change notifications. This caused a
regression for hardware using IEEE80211_HW_WANT_MONITOR_VIF. In monitor
mode, link->conf->bss is uninitialized, but current logic allows these
notifications to reach driver callbacks, causing a deterministic NULL
dereference in drivers like iwldvm. Fix this by validating the BSS
context before driver notification.
Device: Intel Centrino Advanced-n 6205
Fixes: c57e5b974514 ("wifi: mac80211: fix WARN_ON for monitor mode on some devices")
Cc: stable@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Dhyan K Prajapati <dhyaan19022009@gmail.com>
---
net/mac80211/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index b05e313c7..190222c26 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -416,6 +416,8 @@ void ieee80211_link_info_change_notify(struct ieee80211_sub_if_data *sdata,
case NL80211_IFTYPE_MONITOR:
if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
return;
+ if (!link->conf->bss)
+ return;
break;
default:
break;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v5 wireless] mac80211: fix NULL pointer dereference in monitor mode
From: Greg KH @ 2026-02-05 17:50 UTC (permalink / raw)
To: Dhyan K Prajapati
Cc: Johannes Berg, linux-wireless, netdev, stable, dhyaan19022009-hue
In-Reply-To: <20260205174650.4575-1-dhyaan19022009@gmail.com>
On Thu, Feb 05, 2026 at 11:16:50PM +0530, Dhyan K Prajapati wrote:
> From: dhyaan19022009-hue <dhyaan19022009@gmail.com>
Doesn't match your signed-off-by line :(
^ permalink raw reply
* [PATCH v5 wireless] mac80211: fix NULL pointer dereference in monitor mode
From: Dhyan K Prajapati @ 2026-02-05 17:46 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, stable, dhyaan19022009-hue
From: dhyaan19022009-hue <dhyaan19022009@gmail.com>
Crash trace:
RIP: iwlagn_bss_info_changed+0x19d/0x640 [iwldvm]
Code: 49 8b 46 10 <8b> 10
RAX: 0000000000000000 (NULL link->conf->bss)
wifi: mac80211: fix NULL pointer deref regression in link notify
Commit c57e5b974514 ("wifi: mac80211: fix WARN_ON for monitor mode on
some devices") reorganized link change notifications. This caused a
regression for hardware using IEEE80211_HW_WANT_MONITOR_VIF. In monitor
mode, link->conf->bss is uninitialized, but current logic allows these
notifications to reach driver callbacks, causing a deterministic NULL
dereference in drivers like iwldvm. Fix this by validating the BSS
context before driver notification.
Device: Intel Centrino Advanced-n 6205
Fixes: c57e5b974514 ("wifi: mac80211: fix WARN_ON for monitor mode on some devices")
Cc: stable@vger.kernel.org
Cc: netdev@vger.kernel.org
Cc: linux-wireless@vger.kernel.org
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Dhyan K Prajapati <dhyaan19022009@gmail.com>
---
net/mac80211/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index b05e313c7..190222c26 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -416,6 +416,8 @@ void ieee80211_link_info_change_notify(struct ieee80211_sub_if_data *sdata,
case NL80211_IFTYPE_MONITOR:
if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
return;
+ if (!link->conf->bss)
+ return;
break;
default:
break;
--
2.43.0
^ permalink raw reply related
* [PATCH v4 wireless] mac80211: fix NULL pointer dereference in monitor mode Crash trace: RIP: iwlagn_bss_info_changed+0x19d/0x640 [iwldvm] Code: 49 8b 46 10 <8b> 10 RAX: 0000000000000000 (NULL link->conf->bss) wifi: mac80211: fix NULL pointer deref regression in link notify Commit c57e5b974514 ("wifi: mac80211: fix WARN_ON for monitor mode on some devices") reorganized link change notifications. This caused a regression for hardware using IEEE80211_HW_WANT_MONITOR_VIF. In monitor mode, link->conf->bss is uninitialized, but current logic allows these notifications to reach driver callbacks, causing a deterministic NULL dereference in drivers like iwldvm. Fix this by validating the BSS context before driver notification. Device: Intel Centrino Advanced-n 6205 Fixes: c57e5b974514 ("wifi: mac80211: fix WARN_ON for monitor mode on some devices") Cc: stable@vger.kernel.org Cc: netdev@vger.kernel.org Cc: linux-wireless@vger.kernel.org Cc: Johannes Berg <johannes@sipsolutions.net> Signed-off-by: Dhyan K Prajapati <dhyaan19022009@gmail.com>
From: Dhyan K Prajapati @ 2026-02-05 17:44 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, stable, dhyaan19022009-hue
From: dhyaan19022009-hue <dhyaan19022009@gmail.com>
---
net/mac80211/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index b05e313c7..190222c26 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -416,6 +416,8 @@ void ieee80211_link_info_change_notify(struct ieee80211_sub_if_data *sdata,
case NL80211_IFTYPE_MONITOR:
if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
return;
+ if (!link->conf->bss)
+ return;
break;
default:
break;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] rtw: btcoex: clean up style and documentation
From: bubupersonal @ 2026-02-05 17:38 UTC (permalink / raw)
To: Linux Staging; +Cc: Linux Wireless
In-Reply-To: <2026020533-commotion-surfacing-e9ea@gregkh>
Here's the correct patch.
// SPDX-License-Identifier: GPL-2.0
/******************************************************************************
*
* Copyright(c) 2013 Realtek Corporation. All rights reserved.
*
******************************************************************************/
#include <drv_types.h>
#include <rtw_btcoex.h>
#include <hal_btcoex.h>
#define BTCOEX_LPS_RF_ON_TIMEOUT 100
/**
* rtw_btcoex_media_status_notify() - Notify BT coexistence of media status
* @adpt: driver private adapter
* @media_status: connection state
*
* Context: process context
* Locking: caller ensures MLME state is stable
*/
void rtw_btcoex_media_status_notify(struct adapter *adpt, u8 media_status)
{
if (media_status == RT_MEDIA_CONNECT &&
check_fwstate(&adpt->mlmepriv, WIFI_AP_STATE))
rtw_hal_set_hwreg(adpt, HW_VAR_DL_RSVD_PAGE, NULL);
hal_btcoex_MediaStatusNotify(adpt, media_status);
}
/**
* rtw_btcoex_halt_notify() - Notify BT coexistence of device halt
* @adpt: driver private adapter
*
* Context: process context
* Locking: device teardown serialization handled by caller
*/
void rtw_btcoex_halt_notify(struct adapter *adpt)
{
if (!adpt->bup || adpt->bSurpriseRemoved)
return;
hal_btcoex_HaltNotify(adpt);
}
/**
* rtw_btcoex_reject_ap_aggregated_packet() - Control AP-side AMPDU handling
* @adpt: driver private adapter
* @enable: reject aggregation when true
*
* Used by BT coexistence logic to reduce interference by disabling
* AP-side AMPDU negotiation.
*
* Context: process context
* Locking: caller holds appropriate MLME/STA protection
*/
void rtw_btcoex_reject_ap_aggregated_packet(struct adapter *adpt, bool enable)
{
struct mlme_ext_info *mlmeinfo;
struct mlme_priv *mlme;
struct sta_info *sta;
mlme = &adpt->mlmepriv;
mlmeinfo = &adpt->mlmeextpriv.mlmext_info;
if (!enable) {
mlmeinfo->accept_addba_req = true;
return;
}
mlmeinfo->accept_addba_req = false;
sta = rtw_get_stainfo(&adpt->stapriv, get_bssid(mlme));
if (sta)
send_delba(adpt, 0, sta->hwaddr);
}
/**
* rtw_btcoex_lps_enter() - Enter low power state for BT coexistence
* @adpt: driver private adapter
*
* Context: process context
* Locking: power control serialized by caller
*
* This function transitions firmware into LPS mode. State flags are
* updated only after the transition request is issued.
*/
void rtw_btcoex_lps_enter(struct adapter *adpt)
{
struct pwrctrl_priv *pwrpriv;
u8 lps_val;
pwrpriv = adapter_to_pwrctl(adpt);
lps_val = hal_btcoex_LpsVal(adpt);
rtw_set_ps_mode(adpt, PS_MODE_MIN, 0, lps_val, "BTCOEX");
pwrpriv->bpower_saving = true;
}
/**
* rtw_btcoex_lps_leave() - Leave low power state for BT coexistence
* @adpt: driver private adapter
*
* Context: process context
* Locking: power control serialized by caller
*
* Ensures RF is fully powered before clearing power-saving state.
*/
void rtw_btcoex_lps_leave(struct adapter *adpt)
{
struct pwrctrl_priv *pwrpriv;
pwrpriv = adapter_to_pwrctl(adpt);
if (pwrpriv->pwr_mode != PS_MODE_ACTIVE) {
rtw_set_ps_mode(adpt, PS_MODE_ACTIVE, 0, 0,
"BTCOEX");
LPS_RF_ON_check(adpt, BTCOEX_LPS_RF_ON_TIMEOUT);
}
pwrpriv->bpower_saving = false;
}
^ permalink raw reply
* Re: [PATCH v3 wireless] mac80211: fix NULL pointer dereference in monitor mode
From: Greg KH @ 2026-02-05 17:34 UTC (permalink / raw)
To: Dhyan K Prajapati
Cc: Johannes Berg, linux-wireless, netdev, stable, dhyaan19022009-hue
In-Reply-To: <20260205172313.16652-1-dhyaan19022009@gmail.com>
On Thu, Feb 05, 2026 at 10:53:12PM +0530, Dhyan K Prajapati wrote:
> From: dhyaan19022009-hue <dhyaan19022009@gmail.com>
>
> Signed-off-by: dhyaan19022009-hue <dhyaan19022009@gmail.com>
> ---
> net/mac80211/main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index b05e313c7..190222c26 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -416,6 +416,8 @@ void ieee80211_link_info_change_notify(struct ieee80211_sub_if_data *sdata,
> case NL80211_IFTYPE_MONITOR:
> if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
> return;
> + if (!link->conf->bss)
> + return;
> break;
> default:
> break;
> --
> 2.43.0
>
>
Hi,
This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him
a patch that has triggered this response. He used to manually respond
to these common problems, but in order to save his sanity (he kept
writing the same thing over and over, yet to different people), I was
created. Hopefully you will not take offence and will fix the problem
in your patch and resubmit it so that it can be accepted into the Linux
kernel tree.
You are receiving this message because of the following common error(s)
as indicated below:
- You did not specify a description of why the patch is needed, or
possibly, any description at all, in the email body. Please read the
section entitled "The canonical patch format" in the kernel file,
Documentation/process/submitting-patches.rst for what is needed in
order to properly describe the change.
- You did not write a descriptive Subject: for the patch, allowing Greg,
and everyone else, to know what this patch is all about. Please read
the section entitled "The canonical patch format" in the kernel file,
Documentation/process/submitting-patches.rst for what a proper
Subject: line should look like.
- It looks like you did not use your "real" name for the patch on either
the Signed-off-by: line, or the From: line (both of which have to
match). Please read the kernel file,
Documentation/process/submitting-patches.rst for how to do this
correctly.
If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Greg will reply once he has dug out from the pending patches received
from other developers.
thanks,
greg k-h's patch email bot
^ permalink raw reply
* Re: [PATCH v3 wireless] mac80211: fix NULL pointer dereference in monitor mode
From: Greg KH @ 2026-02-05 17:34 UTC (permalink / raw)
To: Dhyan K Prajapati
Cc: Johannes Berg, linux-wireless, netdev, stable, dhyaan19022009-hue
In-Reply-To: <20260205172313.16652-1-dhyaan19022009@gmail.com>
On Thu, Feb 05, 2026 at 10:53:12PM +0530, Dhyan K Prajapati wrote:
> From: dhyaan19022009-hue <dhyaan19022009@gmail.com>
>
> Signed-off-by: dhyaan19022009-hue <dhyaan19022009@gmail.com>
> ---
> net/mac80211/main.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/net/mac80211/main.c b/net/mac80211/main.c
> index b05e313c7..190222c26 100644
> --- a/net/mac80211/main.c
> +++ b/net/mac80211/main.c
> @@ -416,6 +416,8 @@ void ieee80211_link_info_change_notify(struct ieee80211_sub_if_data *sdata,
> case NL80211_IFTYPE_MONITOR:
> if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
> return;
> + if (!link->conf->bss)
> + return;
> break;
> default:
> break;
> --
> 2.43.0
>
>
<formletter>
This is not the correct way to submit patches for inclusion in the
stable kernel tree. Please read:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
for how to do this properly.
</formletter>
^ permalink raw reply
* [PATCH v3 wireless] mac80211: fix NULL pointer dereference in monitor mode
From: Dhyan K Prajapati @ 2026-02-05 17:23 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, netdev, stable, dhyaan19022009-hue
From: dhyaan19022009-hue <dhyaan19022009@gmail.com>
Signed-off-by: dhyaan19022009-hue <dhyaan19022009@gmail.com>
---
net/mac80211/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index b05e313c7..190222c26 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -416,6 +416,8 @@ void ieee80211_link_info_change_notify(struct ieee80211_sub_if_data *sdata,
case NL80211_IFTYPE_MONITOR:
if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
return;
+ if (!link->conf->bss)
+ return;
break;
default:
break;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH v2 2/3] AP: Always re-add stations that use MLO
From: Ramasamy Kaliappan @ 2026-02-05 17:04 UTC (permalink / raw)
To: Benjamin Berg, Rameshkumar Sundaram, hostap
Cc: linux-wireless, Andrei Otcheretianski
In-Reply-To: <97511b524cecf4862d8a83038017c23bc7d715b8.camel@sipsolutions.net>
Hi,
On 1/30/2026 5:32 PM, Benjamin Berg wrote:
> Hi,
>
> On Thu, 2026-01-29 at 22:56 +0530, Rameshkumar Sundaram wrote:
>> On 1/29/2026 3:38 PM, Benjamin Berg wrote:
>>> [SNIP]
>>> That said, to properly fix this we need an nl80211/mac80211 API that
>>> permits us to disable address translation for the frame. Otherwise we
>>> would still get the address translated to the old link address should
>>> the new link address match the MLD address.
>>>
>>
>> That's true—even probe responses get translated when the old link
>> address matches the new link MLD address.
>>
>> Few other cases I encountered:
>> Consider an ML STA with ML address M associated with link A and link B,
>> using link addresses X and Y respectively. If the STA sends an
>> authentication frame with address Y on link A, it gets translated to M
>> (even though link A has no STA with address Y) and forwarded to link B.
>> As a result, hostapd is unaware of the actual TA and queues the
>> authentication reply to the MLD address on link B. This frame will
>> eventually be transmitted over the air on link B with address Y.
>
> Honestly, that type of link confusion seems like a bug. We should be
> able to avoid that as we hopefully know on which link the frame was
> received.
>
>> This will be true even if STA associated in one link and tries to roam
>> to other link of MLD using same link and ML addresses.
>>
>> There also cases where an ML STA roams/re-associates as legacy (non-ML)
>> STA with ML address as link address. The reply would go out with old
>> link address.
>
> Yes, I think that case is similar a station using its MLD Address on
> the association link and returning on another link.
>
>> It seems that address translation at the driver/mac80211 level for
>> management frames could be avoided for both TX and RX, allowing hostapd
>> to handle these frames and their replies more efficiently in cases of
>> roaming and address reuse.
>
> Doing address translation in the TX path is required if the
> hardware/driver should decide on which link to TX the frame. For RX, it
> seems sensible to me to do the translation when it is possible.
>
> I talked a bit to Johannes about this today, and my current proposal
> would be add a new flag that is set when mac80211 did not find (RX) or
> should not use (TX) a STA for the frame.
>
> More specifically I think that we could:
> * Fix the link address based STA lookup to only work when the frame
> was received on the correct link (the bug from above).
> * Make sure we drop robust management frames without a STA as we do
> not want to get into trouble with the next change.
> * Change ieee80211_rx_for_interface so that it uses only
> link_sta_info_get_bss if we are an MLD and sta_info_get_bss
> otherwise.
> Right now, we will find the station if we see the MLD Address in the
> frame even when it is not a valid link address.
> * Add a new nl80211 attribute NL80211_ATTR_FRAME_NO_STA to be used
> together with NL80211_CMD_FRAME for both TX and RX.
> - In the RX case, add the attribute if we have no station. If the
> attribute does not exist, then hostapd should assume the address was
> translated.
> - In the TX case, plumb the information through to mac80211 and avoid
> doing a station lookup based on the address.
>
> I think this would be enough to then solve the problem in hostapd.
>
I feel this approach should work. I'm trying to understand how it
behaves in the following scenario where the STA reconnects with the same
link address but a new(different) MLD address.
Consider a situation where an already associated STA sends a reconnect
request using the same link addresses but a different MLD address.
For example, assume the station was originally connected using M as the
MLD address, with L1 and L2 as its link addresses. When the STA
reconnects (or roam back), it may use a new MLD address B while still
using the same link addresses L1 and L2.
In such a case, mac80211 will still find the existing STA entry based on
the link address, and address translation would map the link address to
the old mld address. Since the STA lookup succeeds,
NL80211_ATTR_FRAME_NO_STA would be set to 0.
How is this expected to be handled in hostapd? I believe hostapd will
also need additional logic to correctly handle this case, since the
link address maps to an already‑known STA, but the MLD address has changed.
Otherwise, hostapd may end up replying to the old MLD address or
associating the frame with the wrong MLD context.
> Benjamin
>
Thanks,
Ramasamy
^ permalink raw reply
* Re: [PATCH] rtw: btcoex: clean up style and documentation
From: Greg KH @ 2026-02-05 16:42 UTC (permalink / raw)
To: bubupersonal; +Cc: Linux Staging, Linux Wireless
In-Reply-To: <OkiaM3C--F-9@tutamail.com>
On Thu, Feb 05, 2026 at 05:18:54PM +0100, bubupersonal@tutamail.com wrote:
> From: Bubuworks <bubupersonal@tutamail.com>
> Date: Thu, 05 Feb 2026 17:25:00 +0200
> Subject: [PATCH] rtw: btcoex: clean up style and documentation
> Signed-off-by: Bubuworks <bubupersonal@tutamail.com>
This looks very odd, are you sure it's correct, because:
> <start of patch>
> >From 0eca95cba2b7bf7b7b4f2fa90734a85fcaa72782 Mon Sep 17 00:00:00 2001
> From: Tejun Heo <tj@kernel.org>
> Date: Wed, 4 Feb 2026 10:07:55 -1000
> Subject: [PATCH] sched_ext: Short-circuit sched_class operations on dead tasks
That's not your patch :(
Something went wrong with your email system :(
^ permalink raw reply
* Re: bot results missing in patchwork
From: Johannes Berg @ 2026-02-05 16:32 UTC (permalink / raw)
To: linux-wireless
In-Reply-To: <2edc78e3581a11c18189b1ac5ee95b0600586f82.camel@sipsolutions.net>
On Thu, 2026-02-05 at 11:28 +0100, Johannes Berg wrote:
> Hi,
>
> Just noticed now that evidently when I did some server shuffling
> yesterday I lost the job that uploads the results to patchwork...
>
> I can't fix it right now, so for now just wanted to say that it's
> missing and that I'm aware. I'll get it fixed soon.
Should be good now. And because I mixed up the new config and made it
link to https://..., I actually gave it a key and certificate now so
that actually works.
johannes
^ permalink raw reply
* [PATCH] rtw: btcoex: clean up style and documentation
From: bubupersonal @ 2026-02-05 16:18 UTC (permalink / raw)
To: Linux Staging; +Cc: Linux Wireless
From: Bubuworks <bubupersonal@tutamail.com>
Date: Thu, 05 Feb 2026 17:25:00 +0200
Subject: [PATCH] rtw: btcoex: clean up style and documentation
Signed-off-by: Bubuworks <bubupersonal@tutamail.com>
<start of patch>
From 0eca95cba2b7bf7b7b4f2fa90734a85fcaa72782 Mon Sep 17 00:00:00 2001
From: Tejun Heo <tj@kernel.org>
Date: Wed, 4 Feb 2026 10:07:55 -1000
Subject: [PATCH] sched_ext: Short-circuit sched_class operations on dead tasks
7900aa699c34 ("sched_ext: Fix cgroup exit ordering by moving sched_ext_free()
to finish_task_switch()") moved sched_ext_free() to finish_task_switch() and
renamed it to sched_ext_dead() to fix cgroup exit ordering issues. However,
this created a race window where certain sched_class ops may be invoked on
dead tasks leading to failures - e.g. sched_setscheduler() may try to switch a
task which finished sched_ext_dead() back into SCX triggering invalid SCX task
state transitions.
Add task_dead_and_done() which tests whether a task is TASK_DEAD and has
completed its final context switch, and use it to short-circuit sched_class
operations which may be called on dead tasks.
Fixes: 7900aa699c34 ("sched_ext: Fix cgroup exit ordering by moving sched_ext_free() to finish_task_switch()")
Reported-by: Andrea Righi <arighi@nvidia.com>
Link: http://lkml.kernel.org/r/20260202151341.796959-1-arighi@nvidia.com
Reviewed-by: Andrea Righi <arighi@nvidia.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
---
kernel/sched/ext.c | 48 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 48 insertions(+)
diff --git a/kernel/sched/ext.c b/kernel/sched/ext.c
index 8f6d8d7f895c..1a5ead4a476e 100644
--- a/kernel/sched/ext.c
+++ b/kernel/sched/ext.c
@@ -194,6 +194,7 @@ MODULE_PARM_DESC(bypass_lb_intv_us, "bypass load balance interval in microsecond
#include <trace/events/sched_ext.h>
static void process_ddsp_deferred_locals(struct rq *rq);
+static bool task_dead_and_done(struct task_struct *p);
static u32 reenq_local(struct rq *rq);
static void scx_kick_cpu(struct scx_sched *sch, s32 cpu, u64 flags);
static bool scx_vexit(struct scx_sched *sch, enum scx_exit_kind kind,
@@ -2618,6 +2619,9 @@ static void set_cpus_allowed_scx(struct task_struct *p,
set_cpus_allowed_common(p, ac);
+ if (task_dead_and_done(p))
+ return;
+
/*
* The effective cpumask is stored in @p->cpus_ptr which may temporarily
* differ from the configured one in @p->cpus_mask. Always tell the bpf
@@ -3033,10 +3037,45 @@ void scx_cancel_fork(struct task_struct *p)
percpu_up_read(&scx_fork_rwsem);
}
+/**
+ * task_dead_and_done - Is a task dead and done running?
+ * @p: target task
+ *
+ * Once sched_ext_dead() removes the dead task from scx_tasks and exits it, the
+ * task no longer exists from SCX's POV. However, certain sched_class ops may be
+ * invoked on these dead tasks leading to failures - e.g. sched_setscheduler()
+ * may try to switch a task which finished sched_ext_dead() back into SCX
+ * triggering invalid SCX task state transitions and worse.
+ *
+ * Once a task has finished the final switch, sched_ext_dead() is the only thing
+ * that needs to happen on the task. Use this test to short-circuit sched_class
+ * operations which may be called on dead tasks.
+ */
+static bool task_dead_and_done(struct task_struct *p)
+{
+ struct rq *rq = task_rq(p);
+
+ lockdep_assert_rq_held(rq);
+
+ /*
+ * In do_task_dead(), a dying task sets %TASK_DEAD with preemption
+ * disabled and __schedule(). If @p has %TASK_DEAD set and off CPU, @p
+ * won't ever run again.
+ */
+ return unlikely(READ_ONCE(p->__state) == TASK_DEAD) &&
+ !task_on_cpu(rq, p);
+}
+
void sched_ext_dead(struct task_struct *p)
{
unsigned long flags;
+ /*
+ * By the time control reaches here, @p has %TASK_DEAD set, switched out
+ * for the last time and then dropped the rq lock - task_dead_and_done()
+ * should be returning %true nullifying the straggling sched_class ops.
+ * Remove from scx_tasks and exit @p.
+ */
raw_spin_lock_irqsave(&scx_tasks_lock, flags);
list_del_init(&p->scx.tasks_node);
raw_spin_unlock_irqrestore(&scx_tasks_lock, flags);
@@ -3062,6 +3101,9 @@ static void reweight_task_scx(struct rq *rq, struct task_struct *p,
lockdep_assert_rq_held(task_rq(p));
+ if (task_dead_and_done(p))
+ return;
+
p->scx.weight = sched_weight_to_cgroup(scale_load_down(lw->weight));
if (SCX_HAS_OP(sch, set_weight))
SCX_CALL_OP_TASK(sch, SCX_KF_REST, set_weight, rq,
@@ -3076,6 +3118,9 @@ static void switching_to_scx(struct rq *rq, struct task_struct *p)
{
struct scx_sched *sch = scx_root;
+ if (task_dead_and_done(p))
+ return;
+
scx_enable_task(p);
/*
@@ -3089,6 +3134,9 @@ static void switching_to_scx(struct rq *rq, struct task_struct *p)
static void switched_from_scx(struct rq *rq, struct task_struct *p)
{
+ if (task_dead_and_done(p))
+ return;
+
scx_disable_task(p);
}
--
2.52.0.windows.1
<end of patch>
^ permalink raw reply related
* [PATCH v2] mac80211: fix NULL pointer dereference in monitor mode
From: dhyaan19022009-hue @ 2026-02-05 14:19 UTC (permalink / raw)
To: Johannes Berg; +Cc: linux-wireless, linux-kernel, Dhyan K Prajapati
From: Dhyan K Prajapati <dhyaan19022009@gmail.com>
When switching an interface to monitor mode on drivers that set the
IEEE80211_HW_WANT_MONITOR_VIF flag, ieee80211_link_info_change_notify()
can pass BSS change notifications to the driver callback even though
monitor interfaces have no associated BSS context (link->conf->bss is NULL)
This triggers a NULL pointer dereference in drivers like iwldvm when
they access BSS-specific fields without checking for NULL.
Example crash on Intel Centrino Advanced-N 6205 (iwldvm):
BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 5295.135825]
fixed the issue by adding a NULL check for link->conf->bss before proceeding to
driver notification
Tested on Intel Centrino Advanced-N 6205 [Taylor Peak] (rev 34)
Signed-off-by: Dhyan K Prajapati <dhyaan19022009@gmail.com>
---
net/mac80211/main.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index b05e313c7..190222c26 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -416,6 +416,8 @@ void ieee80211_link_info_change_notify(struct ieee80211_sub_if_data *sdata,
case NL80211_IFTYPE_MONITOR:
if (!ieee80211_hw_check(&local->hw, WANT_MONITOR_VIF))
return;
+ if (!link->conf->bss)
+ return;
break;
default:
break;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH wireless-next v4 3/3] wifi: mac80211_hwsim: add incumbent signal interference detection support
From: Johannes Berg @ 2026-02-05 12:24 UTC (permalink / raw)
To: Amith A; +Cc: linux-wireless, Aditya Kumar Singh
In-Reply-To: <20260205112146.3997044-4-amith.a@oss.qualcomm.com>
On Thu, 2026-02-05 at 16:51 +0530, Amith A wrote:
>
> +static void hwsim_6ghz_chanctx_iter(struct ieee80211_hw *hw,
> + struct ieee80211_chanctx_conf *conf,
> + void *data)
> +{
> + struct ieee80211_chanctx_conf **out = data;
> +
> + if (conf->def.chan && conf->def.chan->band == NL80211_BAND_6GHZ)
> + *out = conf;
> +}
> +
> +static int hwsim_write_simulate_incumbent_signal(void *dat, u64 val)
> +{
> + struct mac80211_hwsim_data *data = dat;
> + struct ieee80211_chanctx_conf *chanctx_conf = NULL;
> +
> + ieee80211_iter_chan_contexts_atomic(data->hw,
> + hwsim_6ghz_chanctx_iter,
> + &chanctx_conf);
> +
> + if (!chanctx_conf)
> + return -EINVAL;
Wouldn't it make more sense require userspace to write also the
frequency, rather than randomly picking the first 6 GHz chandef?
> +++ b/drivers/net/wireless/virtual/mac80211_hwsim.h
> @@ -343,4 +343,6 @@ enum hwsim_rate_info_attributes {
> HWSIM_RATE_INFO_ATTR_MAX = NUM_HWSIM_RATE_INFO_ATTRS - 1
> };
>
> +/* no longer used - previously used for debugfs iterator */
Hmm?
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v4 1/3] wifi: cfg80211: add support to handle incumbent signal detected event from mac80211/driver
From: Johannes Berg @ 2026-02-05 12:22 UTC (permalink / raw)
To: Amith A; +Cc: linux-wireless, Hari Chandrakanthan
In-Reply-To: <20260205112146.3997044-2-amith.a@oss.qualcomm.com>
On Thu, 2026-02-05 at 16:51 +0530, Amith A wrote:
>
> +++ b/include/net/cfg80211.h
> @@ -10423,4 +10423,27 @@ cfg80211_s1g_get_primary_sibling(struct wiphy *wiphy,
> return ieee80211_get_channel_khz(wiphy, sibling_1mhz_khz);
> }
>
> +
> +/**
> + * cfg80211_incumbent_signal_notify - Notify userspace of incumbent signal detection
> + * @wiphy: the wiphy to use
> + * @chandef: channel definition in which the interference was detected
> + * @signal_interference_bitmap: bitmap indicating interference across 20 MHz segments
> + * @gfp: allocation context for message creation and multicast; pass GFP_ATOMIC
> + * if called from atomic context (e.g. firmware event handler), otherwise
> + * GFP_KERNEL
> + *
> + * Use this function to notify userspace when an incumbent signal is detected on
> + * the operating channel in the 6 GHz band. The notification includes the
> + * current channel definition and a bitmap representing interference across
> + * the operating bandwidth. Each bit in the bitmap corresponds to a 20 MHz
> + * segment, with the lowest bit representing the lowest frequency segment.
> + * Punctured sub-channels are included in the bitmap structure but are always
> + * set to zero since interference detection is not performed on them.
> + */
> +void cfg80211_incumbent_signal_notify(struct wiphy *wiphy,
> + struct cfg80211_chan_def *chandef,
chandef could be const, I guess?
johannes
^ permalink raw reply
* Re: [PATCH wireless-next v4 2/3] wifi: mac80211: add support to handle incumbent signal detected event from driver
From: Johannes Berg @ 2026-02-05 12:21 UTC (permalink / raw)
To: Amith A; +Cc: linux-wireless, Hari Chandrakanthan, Aditya Kumar Singh
In-Reply-To: <20260205112146.3997044-3-amith.a@oss.qualcomm.com>
On Thu, 2026-02-05 at 16:51 +0530, Amith A wrote:
>
> +void ieee80211_incumbent_signal_detected(struct ieee80211_hw *hw,
> + struct ieee80211_chanctx_conf *chanctx_conf,
> + u32 incumbt_sig_intf_bmap)
> +{
> + struct ieee80211_local *local = hw_to_local(hw);
> +
> + trace_api_incumbent_signal_detected(local, chanctx_conf, incumbt_sig_intf_bmap);
> + cfg80211_incumbent_signal_notify(hw->wiphy,
> + &chanctx_conf->def,
> + incumbt_sig_intf_bmap,
> + GFP_ATOMIC);
> +}
> +EXPORT_SYMBOL(ieee80211_incumbent_signal_detected);
There's nothing here that couldn't be done directly by the driver
(except tracing), do we even need this indirection? Caller could just
call cfg80211 directly, no?
johannes
^ permalink raw reply
* [PATCH wireless-next v4 3/3] wifi: mac80211_hwsim: add incumbent signal interference detection support
From: Amith A @ 2026-02-05 11:21 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, amith.a, Aditya Kumar Singh
In-Reply-To: <20260205112146.3997044-1-amith.a@oss.qualcomm.com>
From: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Add a debugfs 'simulate_incumbent_signal_interference' which calls the
function ieee80211_incumbent_signal_detected() to report that incumbent
signal interference has been detected on the current 6 GHz operating
channel. The written value is a bitmap of affected 20 MHz segments.
Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Signed-off-by: Amith A <amith.a@oss.qualcomm.com>
---
drivers/net/wireless/virtual/mac80211_hwsim.c | 33 +++++++++++++++++++
drivers/net/wireless/virtual/mac80211_hwsim.h | 2 ++
2 files changed, 35 insertions(+)
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.c b/drivers/net/wireless/virtual/mac80211_hwsim.c
index 4d9f5f87e814..f1105f97504b 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.c
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.c
@@ -1164,6 +1164,36 @@ static int hwsim_write_simulate_radar(void *dat, u64 val)
DEFINE_DEBUGFS_ATTRIBUTE(hwsim_simulate_radar, NULL,
hwsim_write_simulate_radar, "%llu\n");
+static void hwsim_6ghz_chanctx_iter(struct ieee80211_hw *hw,
+ struct ieee80211_chanctx_conf *conf,
+ void *data)
+{
+ struct ieee80211_chanctx_conf **out = data;
+
+ if (conf->def.chan && conf->def.chan->band == NL80211_BAND_6GHZ)
+ *out = conf;
+}
+
+static int hwsim_write_simulate_incumbent_signal(void *dat, u64 val)
+{
+ struct mac80211_hwsim_data *data = dat;
+ struct ieee80211_chanctx_conf *chanctx_conf = NULL;
+
+ ieee80211_iter_chan_contexts_atomic(data->hw,
+ hwsim_6ghz_chanctx_iter,
+ &chanctx_conf);
+
+ if (!chanctx_conf)
+ return -EINVAL;
+
+ ieee80211_incumbent_signal_detected(data->hw, chanctx_conf, (u32)val);
+
+ return 0;
+}
+
+DEFINE_DEBUGFS_ATTRIBUTE(hwsim_simulate_incumbent_signal, NULL,
+ hwsim_write_simulate_incumbent_signal, "%llu\n");
+
static int hwsim_fops_group_read(void *dat, u64 *val)
{
struct mac80211_hwsim_data *data = dat;
@@ -5832,6 +5862,9 @@ static int mac80211_hwsim_new_radio(struct genl_info *info,
debugfs_create_file("dfs_simulate_radar", 0222,
data->debugfs,
data, &hwsim_simulate_radar);
+ debugfs_create_file("simulate_incumbent_signal_interference", 0200,
+ data->debugfs,
+ data, &hwsim_simulate_incumbent_signal);
if (param->pmsr_capa) {
data->pmsr_capa = *param->pmsr_capa;
diff --git a/drivers/net/wireless/virtual/mac80211_hwsim.h b/drivers/net/wireless/virtual/mac80211_hwsim.h
index c2d06cf852a5..d897aa720ec2 100644
--- a/drivers/net/wireless/virtual/mac80211_hwsim.h
+++ b/drivers/net/wireless/virtual/mac80211_hwsim.h
@@ -343,4 +343,6 @@ enum hwsim_rate_info_attributes {
HWSIM_RATE_INFO_ATTR_MAX = NUM_HWSIM_RATE_INFO_ATTRS - 1
};
+/* no longer used - previously used for debugfs iterator */
+
#endif /* __MAC80211_HWSIM_H */
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next v4 2/3] wifi: mac80211: add support to handle incumbent signal detected event from driver
From: Amith A @ 2026-02-05 11:21 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, amith.a, Hari Chandrakanthan, Aditya Kumar Singh
In-Reply-To: <20260205112146.3997044-1-amith.a@oss.qualcomm.com>
From: Hari Chandrakanthan <quic_haric@quicinc.com>
Add a new API ieee80211_incumbent_signal_detected() that can be used by
wireless drivers to notify the higher layers about the interference of
incumbent signals in 6 GHz band with the operating channel (mandatory to
pass during MLO) and the interference bitmap in which each bit denotes
the affected 20 MHz in the operating channel.
Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com>
Co-developed-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Signed-off-by: Aditya Kumar Singh <aditya.kumar.singh@oss.qualcomm.com>
Signed-off-by: Amith A <amith.a@oss.qualcomm.com>
---
include/net/mac80211.h | 14 ++++++++++++++
net/mac80211/trace.h | 26 ++++++++++++++++++++++++++
net/mac80211/util.c | 14 ++++++++++++++
3 files changed, 54 insertions(+)
diff --git a/include/net/mac80211.h b/include/net/mac80211.h
index 36ae7fe9ddf3..d586eab10f26 100644
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -7899,4 +7899,18 @@ int ieee80211_emulate_switch_vif_chanctx(struct ieee80211_hw *hw,
* Return: %true iff the vif is a NAN interface and NAN is started
*/
bool ieee80211_vif_nan_started(struct ieee80211_vif *vif);
+
+/**
+ * ieee80211_incumbent_signal_detected - inform that an incumbent signal
+ * interference was detected
+ * @hw: pointer as obtained from ieee80211_alloc_hw()
+ * @chanctx_conf: Channel context on which the signal interference was detected.
+ * Mandatory to pass a valid pointer for MLO. For non-MLO %NULL can be
+ * passed
+ * @incumbt_sig_intf_bmap: Bitmap indicating where the incumbent signal was
+ * detected.
+ */
+void ieee80211_incumbent_signal_detected(struct ieee80211_hw *hw,
+ struct ieee80211_chanctx_conf *chanctx_conf,
+ u32 incumbt_sig_intf_bmap);
#endif /* MAC80211_H */
diff --git a/net/mac80211/trace.h b/net/mac80211/trace.h
index 0bfbce157486..74741a61546c 100644
--- a/net/mac80211/trace.h
+++ b/net/mac80211/trace.h
@@ -3136,6 +3136,32 @@ TRACE_EVENT(api_radar_detected,
)
);
+TRACE_EVENT(api_incumbent_signal_detected,
+ TP_PROTO(struct ieee80211_local *local,
+ struct ieee80211_chanctx_conf *chanctx_conf,
+ u32 bitmap),
+
+ TP_ARGS(local, chanctx_conf, bitmap),
+
+ TP_STRUCT__entry(
+ LOCAL_ENTRY
+ CHANDEF_ENTRY
+ __field(u32, bitmap)
+ ),
+
+ TP_fast_assign(
+ LOCAL_ASSIGN;
+ CHANDEF_ASSIGN(&chanctx_conf->def)
+ __entry->bitmap = bitmap;
+ ),
+
+ TP_printk(
+ LOCAL_PR_FMT " Incumbent signal detected."
+ CHANDEF_PR_FMT " Bitmap: 0x%x ",
+ LOCAL_PR_ARG, CHANDEF_PR_ARG, __entry->bitmap
+ )
+);
+
TRACE_EVENT(api_request_smps,
TP_PROTO(struct ieee80211_local *local,
struct ieee80211_sub_if_data *sdata,
diff --git a/net/mac80211/util.c b/net/mac80211/util.c
index 4d5680da7aa0..0e1ee2559130 100644
--- a/net/mac80211/util.c
+++ b/net/mac80211/util.c
@@ -3670,6 +3670,20 @@ void ieee80211_radar_detected(struct ieee80211_hw *hw,
}
EXPORT_SYMBOL(ieee80211_radar_detected);
+void ieee80211_incumbent_signal_detected(struct ieee80211_hw *hw,
+ struct ieee80211_chanctx_conf *chanctx_conf,
+ u32 incumbt_sig_intf_bmap)
+{
+ struct ieee80211_local *local = hw_to_local(hw);
+
+ trace_api_incumbent_signal_detected(local, chanctx_conf, incumbt_sig_intf_bmap);
+ cfg80211_incumbent_signal_notify(hw->wiphy,
+ &chanctx_conf->def,
+ incumbt_sig_intf_bmap,
+ GFP_ATOMIC);
+}
+EXPORT_SYMBOL(ieee80211_incumbent_signal_detected);
+
void ieee80211_chandef_downgrade(struct cfg80211_chan_def *c,
struct ieee80211_conn_settings *conn)
{
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next v4 1/3] wifi: cfg80211: add support to handle incumbent signal detected event from mac80211/driver
From: Amith A @ 2026-02-05 11:21 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, amith.a, Hari Chandrakanthan
In-Reply-To: <20260205112146.3997044-1-amith.a@oss.qualcomm.com>
From: Hari Chandrakanthan <quic_haric@quicinc.com>
When any incumbent signal is detected by an AP/mesh interface operating
in 6 GHz band, FCC mandates the AP/mesh to vacate the channels affected
by it [1].
Add a new API cfg80211_incumbent_signal_detect_event() that can be used
by mac80211 (or full mac drivers) to notify the higher layers about the
signal interference event with the interference bitmap in which each bit
denotes the affected 20 MHz in the operating channel.
Add support for the new nl80211 event and nl80211 attribute as well to
notify userspace on the details about the interference event. Userspace is
expected to process it and take further action - vacate the channel, or
reduce the bandwidth.
[1] - https://apps.fcc.gov/kdb/GetAttachment.html?id=nXQiRC%2B4mfiA54Zha%2BrW4Q%3D%3D&desc=987594%20D02%20U-NII%206%20GHz%20EMC%20Measurement%20v03&tracking_number=277034
Signed-off-by: Hari Chandrakanthan <quic_haric@quicinc.com>
Signed-off-by: Amith A <amith.a@oss.qualcomm.com>
---
include/net/cfg80211.h | 23 +++++++++++++++++++++
include/uapi/linux/nl80211.h | 19 +++++++++++++++++
net/wireless/nl80211.c | 40 ++++++++++++++++++++++++++++++++++++
net/wireless/trace.h | 19 +++++++++++++++++
4 files changed, 101 insertions(+)
diff --git a/include/net/cfg80211.h b/include/net/cfg80211.h
index 0ae0aa7594a3..91c85a896fd6 100644
--- a/include/net/cfg80211.h
+++ b/include/net/cfg80211.h
@@ -10423,4 +10423,27 @@ cfg80211_s1g_get_primary_sibling(struct wiphy *wiphy,
return ieee80211_get_channel_khz(wiphy, sibling_1mhz_khz);
}
+
+/**
+ * cfg80211_incumbent_signal_notify - Notify userspace of incumbent signal detection
+ * @wiphy: the wiphy to use
+ * @chandef: channel definition in which the interference was detected
+ * @signal_interference_bitmap: bitmap indicating interference across 20 MHz segments
+ * @gfp: allocation context for message creation and multicast; pass GFP_ATOMIC
+ * if called from atomic context (e.g. firmware event handler), otherwise
+ * GFP_KERNEL
+ *
+ * Use this function to notify userspace when an incumbent signal is detected on
+ * the operating channel in the 6 GHz band. The notification includes the
+ * current channel definition and a bitmap representing interference across
+ * the operating bandwidth. Each bit in the bitmap corresponds to a 20 MHz
+ * segment, with the lowest bit representing the lowest frequency segment.
+ * Punctured sub-channels are included in the bitmap structure but are always
+ * set to zero since interference detection is not performed on them.
+ */
+void cfg80211_incumbent_signal_notify(struct wiphy *wiphy,
+ struct cfg80211_chan_def *chandef,
+ u32 signal_interference_bitmap,
+ gfp_t gfp);
+
#endif /* __NET_CFG80211_H */
diff --git a/include/uapi/linux/nl80211.h b/include/uapi/linux/nl80211.h
index 54ddbd9a5459..0bda5c05b47a 100644
--- a/include/uapi/linux/nl80211.h
+++ b/include/uapi/linux/nl80211.h
@@ -1361,6 +1361,12 @@
* user space that the NAN new cluster has been joined. The cluster ID is
* indicated by %NL80211_ATTR_MAC.
*
+ * @NL80211_CMD_INCUMBENT_SIGNAL_DETECT: Once any incumbent signal is detected
+ * on the operating channel in 6 GHz band, userspace is notified with the
+ * signal interference bitmap using
+ * %NL80211_ATTR_INCUMBENT_SIGNAL_INTERFERENCE_BITMAP. The current channel
+ * definition is also sent.
+ *
* @NL80211_CMD_MAX: highest used command number
* @__NL80211_CMD_AFTER_LAST: internal use
*/
@@ -1624,6 +1630,8 @@ enum nl80211_commands {
NL80211_CMD_NAN_NEXT_DW_NOTIFICATION,
NL80211_CMD_NAN_CLUSTER_JOINED,
+ NL80211_CMD_INCUMBENT_SIGNAL_DETECT,
+
/* add new commands above here */
/* used to define NL80211_CMD_MAX below */
@@ -2976,6 +2984,15 @@ enum nl80211_commands {
* @NL80211_ATTR_EPP_PEER: A flag attribute to indicate if the peer is an EPP
* STA. Used with %NL80211_CMD_NEW_STA and %NL80211_CMD_ADD_LINK_STA
*
+ * @NL80211_ATTR_INCUMBENT_SIGNAL_INTERFERENCE_BITMAP: u32 attribute specifying
+ * the signal interference bitmap detected on the operating bandwidth for
+ * %NL80211_CMD_INCUMBENT_SIGNAL_DETECT. Each bit represents a 20 MHz
+ * segment, lowest bit corresponds to the lowest 20 MHz segment, in the
+ * operating bandwidth where the interference is detected. Punctured
+ * sub-channels are included in the bitmap structure; however, since
+ * interference detection is not performed on these sub-channels, their
+ * corresponding bits are consistently set to zero.
+ *
* @NUM_NL80211_ATTR: total number of nl80211_attrs available
* @NL80211_ATTR_MAX: highest attribute number currently defined
* @__NL80211_ATTR_AFTER_LAST: internal use
@@ -3546,6 +3563,8 @@ enum nl80211_attrs {
NL80211_ATTR_EPP_PEER,
+ NL80211_ATTR_INCUMBENT_SIGNAL_INTERFERENCE_BITMAP,
+
/* add attributes here, update the policy in nl80211.c */
__NL80211_ATTR_AFTER_LAST,
diff --git a/net/wireless/nl80211.c b/net/wireless/nl80211.c
index 85e30fda4c46..2b4a84794f8e 100644
--- a/net/wireless/nl80211.c
+++ b/net/wireless/nl80211.c
@@ -21045,6 +21045,46 @@ void cfg80211_ch_switch_notify(struct net_device *dev,
}
EXPORT_SYMBOL(cfg80211_ch_switch_notify);
+void cfg80211_incumbent_signal_notify(struct wiphy *wiphy,
+ struct cfg80211_chan_def *chandef,
+ u32 signal_interference_bitmap,
+ gfp_t gfp)
+{
+ struct cfg80211_registered_device *rdev = wiphy_to_rdev(wiphy);
+ struct sk_buff *msg;
+ void *hdr;
+
+ trace_cfg80211_incumbent_signal_notify(wiphy, chandef, signal_interference_bitmap);
+
+ msg = nlmsg_new(NLMSG_DEFAULT_SIZE, gfp);
+ if (!msg)
+ return;
+
+ hdr = nl80211hdr_put(msg, 0, 0, 0, NL80211_CMD_INCUMBENT_SIGNAL_DETECT);
+ if (!hdr)
+ goto nla_put_failure;
+
+ if (nla_put_u32(msg, NL80211_ATTR_WIPHY, rdev->wiphy_idx))
+ goto nla_put_failure;
+
+ if (nl80211_send_chandef(msg, chandef))
+ goto nla_put_failure;
+
+ if (nla_put_u32(msg, NL80211_ATTR_INCUMBENT_SIGNAL_INTERFERENCE_BITMAP,
+ signal_interference_bitmap))
+ goto nla_put_failure;
+
+ genlmsg_end(msg, hdr);
+
+ genlmsg_multicast_netns(&nl80211_fam, wiphy_net(&rdev->wiphy), msg, 0,
+ NL80211_MCGRP_MLME, gfp);
+ return;
+
+nla_put_failure:
+ nlmsg_free(msg);
+}
+EXPORT_SYMBOL(cfg80211_incumbent_signal_notify);
+
void cfg80211_ch_switch_started_notify(struct net_device *dev,
struct cfg80211_chan_def *chandef,
unsigned int link_id, u8 count,
diff --git a/net/wireless/trace.h b/net/wireless/trace.h
index 643ccf4f0227..deb283d9e017 100644
--- a/net/wireless/trace.h
+++ b/net/wireless/trace.h
@@ -4225,6 +4225,25 @@ TRACE_EVENT(cfg80211_nan_cluster_joined,
WDEV_PR_ARG, __entry->cluster_id,
__entry->new_cluster ? " [new]" : "")
);
+
+TRACE_EVENT(cfg80211_incumbent_signal_notify,
+ TP_PROTO(struct wiphy *wiphy,
+ struct cfg80211_chan_def *chandef,
+ u32 signal_interference_bitmap),
+ TP_ARGS(wiphy, chandef, signal_interference_bitmap),
+ TP_STRUCT__entry(
+ WIPHY_ENTRY
+ CHAN_DEF_ENTRY
+ __field(u32, signal_interference_bitmap)
+ ),
+ TP_fast_assign(
+ WIPHY_ASSIGN;
+ CHAN_DEF_ASSIGN(chandef);
+ __entry->signal_interference_bitmap = signal_interference_bitmap;
+ ),
+ TP_printk(WIPHY_PR_FMT ", " CHAN_DEF_PR_FMT ", signal_interference_bitmap=0x%x",
+ WIPHY_PR_ARG, CHAN_DEF_PR_ARG, __entry->signal_interference_bitmap)
+);
#endif /* !__RDEV_OPS_TRACE || TRACE_HEADER_MULTI_READ */
#undef TRACE_INCLUDE_PATH
--
2.34.1
^ permalink raw reply related
* [PATCH wireless-next v4 0/3] wifi: cfg80211/mac80211: add support to handle incumbent signal detected event
From: Amith A @ 2026-02-05 11:21 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, amith.a
This patch series adds support to handle incumbent signal interference
detected event in 6 GHz band. When an incumbent signal is detected by an
AP/mesh interface operating in 6 GHz band, the AP/mesh is expected to
vacate the channels affected by it.
Driver is expected to call the newly introduced API with required
information to notify the interference detection. This information will be
ultimately sent to user space via NL802111 command. User space is expected
to process it and take further action - vacate the channel, or reduce the
bandwidth.
Aditya Kumar Singh (1):
wifi: mac80211_hwsim: add incumbent signal interference detection
support
Hari Chandrakanthan (2):
wifi: cfg80211: add support to handle incumbent signal detected event
from mac80211/driver
wifi: mac80211: add support to handle incumbent signal detected event
from driver
---
Changes in v4:
- Restored gfp_t in cfg80211_incumbent_signal_notify().
- Dropped incumbt_sig_intf_bmap from ieee80211_chanctx_conf and passed
bitmap directly.
- Updated trace/call path: api_incumbent_signal_detected() to take bitmap
- Simplified hwsim: removed helper struct.
Changes in v3:
- Removed the workqueue mechanism in ieee80211_incumbent_signal_detected(),
exported the cfg80211_ function that sends the NL80211 command and called
it from ieee80211_incumbent_signal_detected() directly.
- Renamed nl80211_incumbent_signal_notify() to
cfg80211_incumbent_signal_notify() and removed the gfp argument from it.
Changes in v2:
- Updated the kernel doc of NL80211_ATTR_INCUMBENT_SIGNAL_INTERFERENCE_BITMAP
to include details of how it interacts with puncturing.
- Rebased on ToT
---
drivers/net/wireless/virtual/mac80211_hwsim.c | 33 +++++++++++++++
drivers/net/wireless/virtual/mac80211_hwsim.h | 2 +
include/net/cfg80211.h | 23 +++++++++++
include/net/mac80211.h | 14 +++++++
include/uapi/linux/nl80211.h | 19 +++++++++
net/mac80211/trace.h | 26 ++++++++++++
net/mac80211/util.c | 14 +++++++
net/wireless/nl80211.c | 40 +++++++++++++++++++
net/wireless/trace.h | 19 +++++++++
9 files changed, 190 insertions(+)
base-commit: c30e188bd2a886258be5facb970a804d8ef549b5
--
2.34.1
^ permalink raw reply
* bot results missing in patchwork
From: Johannes Berg @ 2026-02-05 10:28 UTC (permalink / raw)
To: linux-wireless
Hi,
Just noticed now that evidently when I did some server shuffling
yesterday I lost the job that uploads the results to patchwork...
I can't fix it right now, so for now just wanted to say that it's
missing and that I'm aware. I'll get it fixed soon.
johannes
^ permalink raw reply
* [PATCH wireless-next] wifi: mac80211: set default WMM parameters on all links
From: Aishwarya R @ 2026-02-05 9:42 UTC (permalink / raw)
To: johannes; +Cc: linux-wireless, ath12k, Ramanathan Choodamani, Aishwarya R
From: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
Currently, mac80211 only initializes default WMM parameters
on the deflink during do_open(). For MLO cases, this
leaves the additional links without proper WMM defaults
if hostapd does not supply per-link WMM parameters, leading
to inconsistent QoS behavior across links.
Set default WMM parameters for each link during
ieee80211_vif_update_links(), because this ensures all
individual links in an MLD have valid WMM settings during
bring-up and behave consistently across different BSS.
Signed-off-by: Ramanathan Choodamani <quic_rchoodam@quicinc.com>
Signed-off-by: Aishwarya R <aishwarya.r@oss.qualcomm.com>
---
net/mac80211/link.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/mac80211/link.c b/net/mac80211/link.c
index 1e05845872af..b659497680b5 100644
--- a/net/mac80211/link.c
+++ b/net/mac80211/link.c
@@ -281,6 +281,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
struct ieee80211_bss_conf *old[IEEE80211_MLD_MAX_NUM_LINKS];
struct ieee80211_link_data *old_data[IEEE80211_MLD_MAX_NUM_LINKS];
bool use_deflink = old_links == 0; /* set for error case */
+ bool non_sta = sdata->vif.type != NL80211_IFTYPE_STATION;
lockdep_assert_wiphy(sdata->local->hw.wiphy);
@@ -337,6 +338,7 @@ static int ieee80211_vif_update_links(struct ieee80211_sub_if_data *sdata,
link = links[link_id];
ieee80211_link_init(sdata, link_id, &link->data, &link->conf);
ieee80211_link_setup(&link->data);
+ ieee80211_set_wmm_default(&link->data, true, non_sta);
}
if (new_links == 0)
base-commit: c30e188bd2a886258be5facb970a804d8ef549b5
--
2.34.1
^ permalink raw reply related
* Re: [PATCH wireless-next v8 0/3] wifi: initial UHR support
From: Karthikeyan Kathirvel @ 2026-02-05 8:38 UTC (permalink / raw)
To: Johannes Berg, linux-wireless
In-Reply-To: <e0090840157dcb9968e683dab437296871bbd4a5.camel@sipsolutions.net>
On 2/2/2026 4:42 PM, Johannes Berg wrote:
> On Mon, 2026-02-02 at 16:20 +0530, Karthikeyan Kathirvel wrote:
>>
>> Would like to see your approach of NPCA for AP side, since we are
>> working on Enhanced critical update for all UHR operation features(which
>> includes NPCA as well).
>
> So, FWIW, I went over this a few times in my head ... how do we support
> it when one station has NPCA and another doesn't (need a per-STA flag?),
> how do we update the NPCA operation when stations with different
> parameters join/leave the BSS, etc.
>
> Ultimately I decided that I'm going to leave these problems to you ;-)
This I'll check and come back
>
> For now literally all I've implemented for testing is an ability to
> represent NPCA in the chandef (adding npca_chan and npca_punctured
> bitmap to it), and two new nl80211 attributes to configure such a
> chandef.
>
> That won't even be an upstream hostapd patch, just some hack to set the
> NPCA chandef in nl80211 and advertise it in the UHR operation element,
> but it's already good enough to test a single client.
>
If it is a hack that's fine, but any change in NPCA parameters in AP
side should go through Enhanced Critical Update procedure as per spec
> (Oh and nl80211 won't accept that unless the driver advertises NPCA
> support in UHR for the AP interface, which our driver won't do outside
> some testing mode.)
>
> johannes
Sorry for the delayed response
/KK
^ permalink raw reply
* RE: [PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200
From: Loktionov, Aleksandr @ 2026-02-05 8:33 UTC (permalink / raw)
To: Ethan Nelson-Moore
Cc: netdev@vger.kernel.org, linux-wireless@vger.kernel.org,
Johannes Berg, stable@vger.kernel.org, Nguyen, Anthony L,
Kitszel, Przemyslaw, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Stanislav Yakovlev, Alice Michael
In-Reply-To: <CADkSEUiNrMCGzECO2t+Stx7Xnk=bCAp+mk=99FrMZFq4wOmgFQ@mail.gmail.com>
> -----Original Message-----
> From: Ethan Nelson-Moore <enelsonmoore@gmail.com>
> Sent: Thursday, February 5, 2026 9:18 AM
> To: Loktionov, Aleksandr <aleksandr.loktionov@intel.com>
> Cc: netdev@vger.kernel.org; linux-wireless@vger.kernel.org; Johannes
> Berg <johannes@sipsolutions.net>; stable@vger.kernel.org; Nguyen,
> Anthony L <anthony.l.nguyen@intel.com>; Kitszel, Przemyslaw
> <przemyslaw.kitszel@intel.com>; Andrew Lunn <andrew+netdev@lunn.ch>;
> David S. Miller <davem@davemloft.net>; Eric Dumazet
> <edumazet@google.com>; Jakub Kicinski <kuba@kernel.org>; Paolo Abeni
> <pabeni@redhat.com>; Stanislav Yakovlev <stas.yakovlev@gmail.com>;
> Alice Michael <alice.michael@intel.com>
> Subject: Re: [PATCH net-next] net: intel: fix PCI device ID conflict
> between i40e and ipw2200
>
> Hi, Alexandr,
>
> On Thu, Feb 5, 2026 at 12:13 AM Loktionov, Aleksandr
> <aleksandr.loktionov@intel.com> wrote:
> > Commit message could be more detailed.
> > - Why the PCI ID is being reused (if known) Is this actually a reuse
> after EOL, or is there a misunderstanding? The commit message hand-
> waves this critical detail.
> > - Whether this is documented in hardware datasheets
> > - If there are bug reports of the conflict in the wild
> I don't know any of this information. I found this conflict via a
> script I was motivated to write by noticing an ID conflict between
> r8169 and 8139too.
>
> > If it's quite critical fix why not to send it to [PATCH net] ?
> I used that prefix because the patch is against net-next. It will make
> it into stable versions regardless.
>
> Ethan
I thought 'fix' patches must go to net first, isn't it?
^ permalink raw reply
* Re: [PATCH net-next] net: intel: fix PCI device ID conflict between i40e and ipw2200
From: Ethan Nelson-Moore @ 2026-02-05 8:23 UTC (permalink / raw)
To: Johannes Berg
Cc: netdev, linux-wireless, stable, Tony Nguyen, Przemek Kitszel,
Andrew Lunn, David S. Miller, Eric Dumazet, Jakub Kicinski,
Paolo Abeni, Stanislav Yakovlev, Alice Michael,
Aleksandr Loktionov
In-Reply-To: <b7a1e57d6bfde3ea5c9204323341a74325a63ab8.camel@sipsolutions.net>
Hi, Johannes,
On Thu, Feb 5, 2026 at 12:13 AM Johannes Berg <johannes@sipsolutions.net> wrote:
> Right, good solution. How did you figure out that ipw2200 uses OTHER?
> I'd thought about this but was afraid it'd also just use ETHERNET.
I used linux-hardware.org, which is a database of user-contributed
hardware probes. It didn't have any entries for this particular device
ID (which implies the devices affected are rare in the wild and might
explain why no one noticed this before), but I looked at other ipw2200
and i40e IDs - it shows the class code if you click on the individual
probe ID.
> (FWIW, I've found the database internally, but not who maintains it nor
> any historic information in it ... still digging I guess, if only to
> avoid this happening again in the future)
Thanks for looking into this. Have a nice day.
Ethan
^ 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