From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2B964344D81; Wed, 28 Jan 2026 22:34:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769639642; cv=none; b=Q6l3u/8vjk0nQ08Qig3oxTmZ1J3K5JRFjGDUELgrj2y9y11ranYePRd1ZE0eXpoc7TmFXu5inVrpnxwV2NIIzw7wOsFUgC4cY2mNzzzufUuhUSAyRn6mdhErRJ2jvIBuEVSO3Vp1K40sgz7ewyrrxwD/1KqQUHviFhqBGKOSZQ4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769639642; c=relaxed/simple; bh=Igh4cD88rLtWgMOfnORH/Vs+R3zOyCvczFSHP9CmAgU=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=pNFTOVOBs/gdamQEVaFOslB1cY7tFY5rID0dcYRZrzguXzeliwzHMjzs9WQZUfwA0GMmo8fZ9P5Qk0ukEJ7Q7979706nmRpjjHoEQbH+Vo1694CFQCvjw3bcPR0dauCC17GZCYgt/uI49c7HXbxcjcS1pvxNjtTQRy5t3L/4SrU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oXYi5aLM; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="oXYi5aLM" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 56487C116C6; Wed, 28 Jan 2026 22:34:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1769639642; bh=Igh4cD88rLtWgMOfnORH/Vs+R3zOyCvczFSHP9CmAgU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=oXYi5aLMsIbwfKGeIL1GDOK8WvA9dwkLU/dHKNnW9HWPHde8/PUo19c0SperXt1M7 OlLJWloJdL7PjqUKnFEAEv3Nm/G88vnQMAXAhQrXxpAiQ8mCVU1FsivXKJSZTY6I7O JxRe+vDbYxRxeMbi0xirBQ39bhVYxi8Iej5aoiKbQkAmxvmVEFlV/Na/QX99fJgHgy Ghd+XoaV2l1+HZknTrxItgjNaRAzM3iw3uuoRG5D+ywqE9c9LuLg0mCZnrz0yLgZMg VedRphIrDPv8X7iucpKvBKNoGb2tiwdb3W4J0gwp9CMojUptreAxmoFrWm+u55Z/6/ AsHe5m1mqCtEQ== From: Sasha Levin To: patches@lists.linux.dev, stable@vger.kernel.org Cc: Miri Korenblit , Johannes Berg , Sasha Levin , johannes@sipsolutions.net, linux-wireless@vger.kernel.org Subject: [PATCH AUTOSEL 6.18-6.1] wifi: mac80211: correctly check if CSA is active Date: Wed, 28 Jan 2026 17:33:14 -0500 Message-ID: <20260128223332.2806589-16-sashal@kernel.org> X-Mailer: git-send-email 2.51.0 In-Reply-To: <20260128223332.2806589-1-sashal@kernel.org> References: <20260128223332.2806589-1-sashal@kernel.org> Precedence: bulk X-Mailing-List: linux-wireless@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore X-stable-base: Linux 6.18.7 Content-Transfer-Encoding: 8bit From: Miri Korenblit [ Upstream commit db1d0b6ab11f612ea8a327663a578c8946efeee9 ] We are not adding an interface if an existing one is doing CSA. But the check won't work for MLO station interfaces, since for those, vif->bss_conf is zeroed out. Fix this by checking if any link of the vif has an active CSA. Reviewed-by: Johannes Berg Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20260111191912.7ceff62fc561.Ia38d27f42684d1cfd82d930d232bd5dea6ab9282@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin --- LLM Generated explanations, may be completely bogus: Now I have a complete picture. Let me analyze this commit comprehensively. ## Analysis ### 1. COMMIT MESSAGE ANALYSIS **Subject**: "wifi: mac80211: correctly check if CSA is active" The commit clearly describes a bug fix - the existing CSA (Channel Switch Announcement) check doesn't work properly for MLO (Multi-Link Operation) station interfaces. The message explains: - The problem: "the check won't work for MLO station interfaces, since for those, vif->bss_conf is zeroed out" - The fix: "checking if any link of the vif has an active CSA" **Tags present**: - Reviewed-by: Johannes Berg (mac80211 maintainer) - strong credibility signal - Signed-off-by: Miri Korenblit (Intel wireless developer) - Link to mailing list No explicit Fixes: tag, but that's expected for commits we're reviewing. ### 2. CODE CHANGE ANALYSIS **The Bug:** The original code at line 379: ```c if (nsdata->vif.bss_conf.csa_active) return -EBUSY; ``` This check is used in `ieee80211_check_concurrent_iface()` to prevent adding a new interface while an existing interface is performing a channel switch operation. **Why it's broken for MLO:** For MLO (Multi-Link Operation) station interfaces introduced in WiFi 7 (802.11be): - `vif->bss_conf` is zeroed out by design - Each link has its own BSS configuration stored in `link_conf[link_id]` - The CSA state (`csa_active`) is per-link, not per-VIF - Checking `vif->bss_conf.csa_active` will always return `false` for MLO interfaces, even if one of the links is actively switching channels **The Fix:** ```c struct ieee80211_link_data *link; ... for_each_link_data(nsdata, link) { if (link->conf->csa_active) return -EBUSY; } ``` This properly iterates through all valid links and checks if ANY link has an active CSA. The `for_each_link_data` macro: - For non-MLO interfaces: iterates once with the single (deflink) link - For MLO interfaces: iterates through all links with bits set in `valid_links` **Technical mechanism**: The fix is correct because it unifies the check - it works for both MLO and non-MLO interfaces while maintaining the same semantics. ### 3. CLASSIFICATION This is clearly a **bug fix**, not a new feature: - The concurrent interface protection during CSA was always intended to work - It just doesn't work for the newer MLO interface type - This is a correctness fix for existing functionality ### 4. SCOPE AND RISK ASSESSMENT **Lines changed**: Small - adds ~6 lines, removes 2 lines (net +4) **Files touched**: 1 file (net/mac80211/iface.c) **Complexity**: Low - simple loop iteration replacing a single field access **Subsystem**: mac80211 WiFi subsystem - widely used but WiFi-specific **Risk level**: LOW - The change is straightforward and the logic is sound - The `for_each_link_data` macro is designed for exactly this use case - Reviewed by Johannes Berg, the mac80211 maintainer - Failure mode: If the fix doesn't work, we're no worse than before (still have the bug) ### 5. USER IMPACT **Who is affected?**: Users with MLO-capable WiFi hardware (WiFi 7 / 802.11be devices) **Severity**: Medium - Without this fix: - A new interface could be incorrectly allowed to be added during an ongoing channel switch on an MLO interface - This could cause interference, connectivity issues, or undefined behavior - Channel switches are relatively rare events, so impact is somewhat limited ### 6. STABILITY INDICATORS - **Reviewed-by**: Johannes Berg (mac80211 maintainer) - strong positive signal - Author: Miri Korenblit from Intel - active wireless developer ### 7. DEPENDENCY CHECK **Critical dependency**: This fix uses the `for_each_link_data` macro which was introduced in commit f61c7b3d442be ("wifi: mac80211: Add link iteration macro for link data") in kernel v6.16. **Backport applicability**: - **v6.16+**: Can be applied directly - has the macro - **v6.1-v6.15**: Would require either: 1. Backporting the `for_each_link_data` macro first, OR 2. Writing an alternative fix using open-coded link iteration MLO support was introduced in v6.1, so the bug exists in all kernels v6.1 through current that have MLO station interface support. ### Summary | Criteria | Assessment | |----------|------------| | Obviously correct | YES - simple iteration fix | | Fixes real bug | YES - incorrect CSA check for MLO | | Important issue | MEDIUM - affects interface addition during channel switch | | Small and contained | YES - 4 net lines changed | | No new features | YES - fixes existing feature | | Applies cleanly | DEPENDS - needs v6.16+ for macro dependency | ### VERDICT This is a legitimate bug fix for MLO WiFi support: - It fixes a real, demonstrable bug where CSA detection fails for MLO interfaces - The fix is small, surgical, and well-reviewed - It doesn't introduce new features or change APIs - It improves correctness of existing functionality **However**, there are important caveats: 1. The fix has a dependency on the `for_each_link_data` macro (introduced in v6.16) 2. For stable trees before v6.16, a backport would need the macro too or use an alternative approach 3. MLO is relatively new technology (WiFi 7), so the affected user base is smaller Given that this fix: - Is obviously correct and addresses a real bug - Was reviewed by the subsystem maintainer - Has low risk of regression - Affects real user scenarios (channel switching during interface operations) The fix is appropriate for stable backporting to kernels that have both MLO support and the `for_each_link_data` macro (v6.16+). For older stable trees (v6.1-v6.15), a modified backport with the macro or open- coded iteration would be needed. **YES** net/mac80211/iface.c | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/net/mac80211/iface.c b/net/mac80211/iface.c index 0ca55b9655a7f..72c129478da08 100644 --- a/net/mac80211/iface.c +++ b/net/mac80211/iface.c @@ -350,6 +350,8 @@ static int ieee80211_check_concurrent_iface(struct ieee80211_sub_if_data *sdata, /* we hold the RTNL here so can safely walk the list */ list_for_each_entry(nsdata, &local->interfaces, list) { if (nsdata != sdata && ieee80211_sdata_running(nsdata)) { + struct ieee80211_link_data *link; + /* * Only OCB and monitor mode may coexist */ @@ -376,8 +378,10 @@ static int ieee80211_check_concurrent_iface(struct ieee80211_sub_if_data *sdata, * will not add another interface while any channel * switch is active. */ - if (nsdata->vif.bss_conf.csa_active) - return -EBUSY; + for_each_link_data(nsdata, link) { + if (link->conf->csa_active) + return -EBUSY; + } /* * The remaining checks are only performed for interfaces -- 2.51.0