[PATCH AUTOSEL 6.6 41/62] wifi: mac80211: VLAN traffic in multicast path

[Sasha Levin <sashal@kernel.org>]

From: Muna Sinada <muna.sinada@oss.qualcomm.com>

[ Upstream commit 1a4a6a22552ca9d723f28a1fe35eab1b9b3d8b33 ]

Currently for MLO, sending out multicast frames on each link is handled by
mac80211 only when IEEE80211_HW_MLO_MCAST_MULTI_LINK_TX flag is not set.

Dynamic VLAN multicast traffic utilizes software encryption.
Due to this, mac80211 should handle transmitting multicast frames on
all links for multicast VLAN traffic.

Signed-off-by: Muna Sinada <muna.sinada@oss.qualcomm.com>
Link: https://patch.msgid.link/20250325213125.1509362-4-muna.sinada@oss.qualcomm.com
[remove unnecessary parentheses]
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

**YES** This commit should be backported to stable kernel trees. Here's
my detailed analysis: ## Backporting Analysis: YES ### Nature of the
Change This is a **targeted bug fix** that addresses a functional gap in
MLO (Multi-Link Operation) multicast handling for AP_VLAN interfaces.
The commit extends existing logic rather than introducing new features.
### Technical Assessment **The Problem Fixed:** The original code in
`ieee80211_subif_start_xmit()` only handled `NL80211_IFTYPE_AP`
interfaces for MLO multicast transmission, but completely missed
`NL80211_IFTYPE_AP_VLAN` interfaces. This created a behavioral
inconsistency where: - AP interfaces: Properly handled MLO multicast
transmission via `ieee80211_mlo_multicast_tx()` - AP_VLAN interfaces:
Fell through to normal transmission path, bypassing MLO multicast
coordination **The Fix Applied:** ```c } else if
(ieee80211_vif_is_mld(&sdata->vif) && - sdata->vif.type ==
NL80211_IFTYPE_AP && - !ieee80211_hw_check(&sdata->local->hw,
MLO_MCAST_MULTI_LINK_TX)) { + ((sdata->vif.type == NL80211_IFTYPE_AP &&
+ !ieee80211_hw_check(&sdata->local->hw, MLO_MCAST_MULTI_LINK_TX)) || +
(sdata->vif.type == NL80211_IFTYPE_AP_VLAN && +
!sdata->wdev.use_4addr))) { ``` This change: 1. **Extends existing
conditional logic** to include AP_VLAN interfaces 2. **Uses existing
infrastructure** (`ieee80211_mlo_multicast_tx()`) 3. **Adds proper
validation** (excludes 4-address/WDS mode via `!use_4addr`) ### Risk
Analysis: LOW RISK **Minimal Change Scope:** - Single conditional
modification in well-established code path - No new functions, data
structures, or APIs introduced - Uses existing MLO multicast
transmission infrastructure **Well-Contained Impact:** - Only affects
MLO multicast transmission for AP_VLAN interfaces - Preserved existing
behavior for all other interface types - Added validation ensures
appropriate application scope **Backward Compatibility:** - No changes
to external interfaces or user-visible behavior - No impact on non-MLO
or non-VLAN configurations - Maintains existing AP interface behavior
unchanged ### Comparison with Similar Commits This commit aligns with
**Similar Commit #4** (MLD address translation fix - Status: YES): -
Both are targeted bug fixes for MLO functionality - Both address
specific functional gaps rather than adding new features - Both use
existing infrastructure to correct behavioral issues - Both have minimal
risk profiles suitable for stable backporting **Contrasts with rejected
commits:** - Unlike Similar Commits #1, #2: This is not implementing new
MLO features - Unlike Similar Commit #3: This is not changing
encapsulation behavior - Unlike Similar Commit #5: This is not removing
functionality ### Production Impact **Functional Benefits:** - **Fixes
MLO+VLAN deployments**: Enables proper multicast operation in combined
MLO/VLAN environments - **Consistency**: Ensures uniform multicast
handling across AP and AP_VLAN interface types - **Reliability**:
Prevents potential multicast delivery issues in enterprise VLAN
configurations **Real-World Relevance:** - AP_VLAN interfaces are
commonly used in enterprise environments for traffic segmentation - MLO
is increasingly deployed in Wi-Fi 7 scenarios - The combination creates
practical deployment scenarios where this fix is needed ### Stable Tree
Criteria Compliance ✅ **Important bug fix**: Addresses functional gap
affecting MLO+VLAN deployments ✅ **Minimal risk**: Single conditional
extension with clear validation ✅ **No architectural changes**: Uses
existing MLO multicast infrastructure ✅ **Well-contained**: Affects only
specific interface type in specific scenario ✅ **Production relevant**:
Impacts real-world enterprise VLAN configurations This commit represents
a clear bug fix that resolves a functional inconsistency in MLO
multicast handling, making it well-suited for stable kernel backporting
according to established criteria.

 net/mac80211/tx.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/net/mac80211/tx.c b/net/mac80211/tx.c
index 45a093d3f1fa7..ec5469add68a2 100644
--- a/net/mac80211/tx.c
+++ b/net/mac80211/tx.c
@@ -4507,8 +4507,10 @@ netdev_tx_t ieee80211_subif_start_xmit(struct sk_buff *skb,
 						     IEEE80211_TX_CTRL_MLO_LINK_UNSPEC,
 						     NULL);
 	} else if (ieee80211_vif_is_mld(&sdata->vif) &&
-		   sdata->vif.type == NL80211_IFTYPE_AP &&
-		   !ieee80211_hw_check(&sdata->local->hw, MLO_MCAST_MULTI_LINK_TX)) {
+		   ((sdata->vif.type == NL80211_IFTYPE_AP &&
+		     !ieee80211_hw_check(&sdata->local->hw, MLO_MCAST_MULTI_LINK_TX)) ||
+		    (sdata->vif.type == NL80211_IFTYPE_AP_VLAN &&
+		     !sdata->wdev.use_4addr))) {
 		ieee80211_mlo_multicast_tx(dev, skb);
 	} else {
 normal:
-- 
2.39.5