kernel.git/net/mac80211/link.c, branch linux-6.15.y

wifi: mac80211: avoid weird state in error path

2025-08-20T16:36:06Z

[ Upstream commit be1ba9ed221ffb95a8bb15f4c83d0694225ba808 ] If we get to the error path of ieee80211_prep_connection, for example because of a FW issue, then ieee80211_vif_set_links is called with 0. But the call to drv_change_vif_links from ieee80211_vif_update_links will probably fail as well, for the same reason. In this case, the valid_links and active_links bitmaps will be reverted to the value of the failing connection. Then, in the next connection, due to the logic of ieee80211_set_vif_links_bitmaps, valid_links will be set to the ID of the new connection assoc link, but the active_links will remain with the ID of the old connection's assoc link. If those IDs are different, we get into a weird state of valid_links and active_links being different. One of the consequences of this state is to call drv_change_vif_links with new_links as 0, since the & operation between the bitmaps will be 0. Since a removal of a link should always succeed, ignore the return value of drv_change_vif_links if it was called to only remove links, which is the case for the ieee80211_prep_connection's error path. That way, the bitmaps will not be reverted to have the value from the failing connection and will have 0, so the next connection will have a good state. Signed-off-by: Miri Korenblit Reviewed-by: Johannes Berg Link: https://patch.msgid.link/20250609213231.ba2011fb435f.Id87ff6dab5e1cf757b54094ac2d714c656165059@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: mac80211: finish link init before RCU publish

2025-07-06T09:04:15Z

[ Upstream commit d87c3ca0f8f1ca4c25f2ed819e954952f4d8d709 ] Since the link/conf pointers can be accessed without any protection other than RCU, make sure the data is actually set up before publishing the structures. Fixes: b2e8434f1829 ("wifi: mac80211: set up/tear down client vif links properly") Link: https://patch.msgid.link/20250624130749.9a308b713c74.I4a80f5eead112a38730939ea591d2e275c721256@changeid Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin

wifi: mac80211: Create separate links for VLAN interfaces

2025-07-06T09:04:15Z

[ Upstream commit 90233b0ad215efc9ea56a7c0b09021bcd4eea4ac ] Currently, MLD links for an AP_VLAN interface type is not fully supported. Add allocation of separate links for each VLAN interface and copy chanctx and chandef of AP bss to VLAN where necessary. Separate links are created because for Dynamic VLAN each link will have its own default_multicast_key. Signed-off-by: Muna Sinada Link: https://patch.msgid.link/20250325213125.1509362-3-muna.sinada@oss.qualcomm.com Signed-off-by: Johannes Berg Stable-dep-of: d87c3ca0f8f1 ("wifi: mac80211: finish link init before RCU publish") Signed-off-by: Sasha Levin

Merge git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net

2024-11-01T01:10:07Z

Cross-merge networking fixes after downstream PR (net-6.12-rc6). Conflicts: drivers/net/wireless/intel/iwlwifi/mvm/mld-mac80211.c cbe84e9ad5e2 ("wifi: iwlwifi: mvm: really send iwl_txpower_constraints_cmd") 188a1bf89432 ("wifi: mac80211: re-order assigning channel in activate links") https://lore.kernel.org/all/20241028123621.7bbb131b@canb.auug.org.au/ net/mac80211/cfg.c c4382d5ca1af ("wifi: mac80211: update the right link for tx power") 8dd0498983ee ("wifi: mac80211: Fix setting txpower with emulate_chanctx") drivers/net/ethernet/intel/ice/ice_ptp_hw.h 6e58c3310622 ("ice: fix crash on probe for DPLL enabled E810 LOM") e4291b64e118 ("ice: Align E810T GPIO to other products") ebb2693f8fbd ("ice: Read SDP section from NVM for pin definitions") ac532f4f4251 ("ice: Cleanup unused declarations") https://lore.kernel.org/all/20241030120524.1ee1af18@canb.auug.org.au/ No adjacent changes. Signed-off-by: Jakub Kicinski

wifi: mac80211: re-order assigning channel in activate links

2024-10-23T15:26:14Z

The current flow in _ieee80211_set_active_links() does not align with the operational requirements of drivers that groups multiple hardware under a single wiphy. These drivers (e.g ath12k) rely on channel assignment to determine the appropriate hardware for each link. Without this, the drivers cannot correctly establish the link interface. Currently in _ieee80211_set_active_links(), after calling drv_change_vif_links() on the driver, the state of all connected stations is updated via drv_change_sta_links(). This is followed by handling keys in the links, and finally, assigning the channel to the links. Consequently, drv_change_sta_links() prompts drivers to create the station entry at their level and within their firmware. However, since channels have not yet been assigned to links at this stage, drivers have not created the necessary link interface for establishing link stations, leading to failures in activating the links. Therefore, re-order the logic so that after drv_change_vif_links() and removing the old links, channels are assigned to newly added links. Following this, the flow proceeds to station handling. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20241001085034.2745669-1-quic_adisi@quicinc.com [Johannes: fix iwlwifi to deal with the changes] Reviewed-by: Miriam Rachel Korenblit Signed-off-by: Johannes Berg

wifi: mac80211: update the right link for tx power

2024-10-23T14:43:22Z

Stop looking at deflink and start using the actual link. Initialize the power settings upon link init. Signed-off-by: Emmanuel Grumbach Signed-off-by: Miri Korenblit Link: https://patch.msgid.link/20241007144851.2685dab8e1ab.I1d82cbdb2dda020aee4a225bd9a134f7d82dd810@changeid Signed-off-by: Johannes Berg

wifi: mac80211: Convert color collision detection to wiphy work

2024-10-08T19:24:19Z

Call to ieee80211_color_collision_detection_work() needs wiphy lock to be held (see lockdep assert in cfg80211_bss_color_notify()). Not locking wiphy causes the following lockdep error: WARNING: CPU: 2 PID: 42 at net/wireless/nl80211.c:19505 cfg80211_bss_color_notify+0x1a4/0x25c Modules linked in: CPU: 2 PID: 42 Comm: kworker/u8:3 Tainted: G W 6.4.0-02327-g36c6cb260481 #1048 Hardware name: Workqueue: phy1 ieee80211_color_collision_detection_work pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cfg80211_bss_color_notify+0x1a4/0x25c lr : cfg80211_bss_color_notify+0x1a0/0x25c sp : ffff000002947d00 x29: ffff000002947d00 x28: ffff800008e1a000 x27: ffff000002bd4705 x26: ffff00000d034000 x25: ffff80000903cf40 x24: 0000000000000000 x23: ffff00000cb70720 x22: 0000000000800000 x21: ffff800008dfb008 x20: 000000000000008d x19: ffff00000d035fa8 x18: 0000000000000010 x17: 0000000000000001 x16: 000003564b1ce96a x15: 000d69696d057970 x14: 000000000000003b x13: 0000000000000001 x12: 0000000000040000 x11: 0000000000000001 x10: ffff80000978f9c0 x9 : ffff0000028d3174 x8 : ffff800008e30000 x7 : 0000000000000000 x6 : 0000000000000028 x5 : 000000000002f498 x4 : ffff00000d034a80 x3 : 0000000000800000 x2 : ffff800016143000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: cfg80211_bss_color_notify+0x1a4/0x25c ieee80211_color_collision_detection_work+0x20/0x118 process_one_work+0x294/0x554 worker_thread+0x70/0x440 kthread+0xf4/0xf8 ret_from_fork+0x10/0x20 irq event stamp: 77372 hardirqs last enabled at (77371): [] _raw_spin_unlock_irq+0x2c/0x4c hardirqs last disabled at (77372): [] el1_dbg+0x20/0x48 softirqs last enabled at (77350): [] batadv_send_outstanding_bcast_packet+0xb8/0x120 softirqs last disabled at (77348): [] batadv_send_outstanding_bcast_packet+0x80/0x120 The wiphy lock cannot be taken directly from color collision detection delayed work (ieee80211_color_collision_detection_work()) because this work is cancel_delayed_work_sync() under this wiphy lock causing a potential deadlock( see [0] for details). To fix that ieee80211_color_collision_detection_work() could be converted to a wiphy work and cancel_delayed_work_sync() can be simply replaced by wiphy_delayed_work_cancel() serving the same purpose under wiphy lock. This could potentially fix [1]. [0]: https://lore.kernel.org/linux-wireless/D4A40Q44OAY2.W3SIF6UEPBUN@freebox.fr/ [1]: https://lore.kernel.org/lkml/000000000000612f290618eee3e5@google.com/ Reported-by: Nicolas Escande Signed-off-by: Remi Pommarel Link: https://patch.msgid.link/20240924192805.13859-3-repk@triplefau.lt Signed-off-by: Johannes Berg

wifi: mac80211: handle DFS per link

2024-09-06T11:01:05Z

In order to support DFS with MLO, handle the link ID now passed from cfg80211, adjust the code to do everything per link and call the notifications to cfg80211 correctly. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20240906064426.2101315-7-quic_adisi@quicinc.com Signed-off-by: Johannes Berg

Revert "wifi: mac80211: move radar detect work to sdata"

2024-09-06T11:01:04Z

This reverts commit ce9e660ef32e ("wifi: mac80211: move radar detect work to sdata"). To enable radar detection with MLO, it’s essential to handle it on a per-link basis. This is because when using MLO, multiple links may already be active and beaconing. In this scenario, another link should be able to initiate a radar detection. Also, if underlying links are associated with different hardware devices but grouped together for MLO, they could potentially start radar detection simultaneously. Therefore, it makes sense to manage radar detection settings separately for each link by moving them back to a per-link data structure. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20240906064426.2101315-2-quic_adisi@quicinc.com Signed-off-by: Johannes Berg

wifi: mac80211: cancel color change finalize work when link is stopped

2024-07-08T16:28:47Z

The color change finalize work might be called after the link is stopped, which might lead to a kernel crash. Signed-off-by: Michael-CY Lee Link: https://patch.msgid.link/20240705074326.11172-1-michael-cy.lee@mediatek.com Signed-off-by: Johannes Berg