wireguard-linux/net/mac80211, branch jd/bump-compilers

wifi: mac80211: use two-phase skb reclamation in ieee80211_do_stop()

2024-09-09T09:45:06Z

Since '__dev_queue_xmit()' should be called with interrupts enabled, the following backtrace: ieee80211_do_stop() ... spin_lock_irqsave(&local->queue_stop_reason_lock, flags) ... ieee80211_free_txskb() ieee80211_report_used_skb() ieee80211_report_ack_skb() cfg80211_mgmt_tx_status_ext() nl80211_frame_tx_status() genlmsg_multicast_netns() genlmsg_multicast_netns_filtered() nlmsg_multicast_filtered() netlink_broadcast_filtered() do_one_broadcast() netlink_broadcast_deliver() __netlink_sendskb() netlink_deliver_tap() __netlink_deliver_tap_skb() dev_queue_xmit() __dev_queue_xmit() ; with IRQS disabled ... spin_unlock_irqrestore(&local->queue_stop_reason_lock, flags) issues the warning (as reported by syzbot reproducer): WARNING: CPU: 2 PID: 5128 at kernel/softirq.c:362 __local_bh_enable_ip+0xc3/0x120 Fix this by implementing a two-phase skb reclamation in 'ieee80211_do_stop()', where actual work is performed outside of a section with interrupts disabled. Fixes: 5061b0c2b906 ("mac80211: cooperate more with network namespaces") Reported-by: syzbot+1a3986bbd3169c307819@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=1a3986bbd3169c307819 Signed-off-by: Dmitry Antipov Link: https://patch.msgid.link/20240906123151.351647-1-dmantipov@yandex.ru Signed-off-by: Johannes Berg

wifi: mac80211: handle ieee80211_radar_detected() for MLO

2024-09-06T11:01:05Z

Currently DFS works under assumption there could be only one channel context in the hardware. Hence, drivers just calls the function ieee80211_radar_detected() passing the hardware structure. However, with MLO, this obviously will not work since number of channel contexts will be more than one and hence drivers would need to pass the channel information as well on which the radar is detected. Also, when radar is detected in one of the links, other link's CAC should not be cancelled. Hence, in order to support DFS with MLO, do the following changes - * Add channel context conf pointer as an argument to the function ieee80211_radar_detected(). During MLO, drivers would have to pass on which channel context conf radar is detected. Otherwise, drivers could just pass NULL. * ieee80211_radar_detected() will iterate over all channel contexts present and * if channel context conf is passed, only mark that as radar detected * if NULL is passed, then mark all channel contexts as radar detected * Then as usual, schedule the radar detected work. * In the worker, go over all the contexts again and for all such context which is marked with radar detected, cancel the ongoing CAC by calling ieee80211_dfs_cac_cancel() and then notify cfg80211 via cfg80211_radar_event(). * To cancel the CAC, pass the channel context as well where radar is detected to ieee80211_dfs_cac_cancel(). This ensures that CAC is canceled only on the links using the provided context, leaving other links unaffected. This would also help in scenarios where there is split phy 5 GHz radio, which is capable of DFS channels in both lower and upper band. In this case, simultaneous radars can be detected. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20240906064426.2101315-9-quic_adisi@quicinc.com Signed-off-by: Johannes Berg

wifi: cfg80211/mac80211: use proper link ID for DFS

2024-09-06T11:01:05Z

Now that all APIs have support to handle DFS per link, use proper link ID instead of 0. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20240906064426.2101315-8-quic_adisi@quicinc.com 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

wifi: cfg80211: handle DFS per link

2024-09-06T11:01:05Z

Currently, during starting a radar detection, no link id information is parsed and passed down. In order to support starting radar detection during Multi Link Operation, it is required to pass link id as well. Add changes to first parse and then pass link id in the start radar detection path. Additionally, update notification APIs to allow drivers/mac80211 to pass the link ID. However, everything is handled at link 0 only until all API's are ready to handle it per link. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20240906064426.2101315-6-quic_adisi@quicinc.com Signed-off-by: Johannes Berg

wifi: cfg80211: move DFS related members to links[] in wireless_dev

2024-09-06T11:01:05Z

A few members related to DFS handling are currently under per wireless device data structure. However, in order to support DFS with MLO, there is a need to have them on a per-link manner. Hence, as a preliminary step, move members cac_started, cac_start_time and cac_time_ms to be on a per-link basis. Since currently, link ID is not known at all places, use default value of 0 for now. Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20240906064426.2101315-5-quic_adisi@quicinc.com Signed-off-by: Johannes Berg

wifi: mac80211: remove label usage in ieee80211_start_radar_detection()

2024-09-06T11:01:04Z

After locks rework [1], ieee80211_start_radar_detection() function is no longer acquiring any lock as such explicitly. Hence, it is not unlocking anything as well. However, label "out_unlock" is still used which creates confusion. Also, now there is no need of goto label as such. Get rid of the goto logic and use direct return statements. [1]: https://lore.kernel.org/all/20230828135928.b1c6efffe9ad.I4aec875e25abc9ef0b5ad1e70b5747fd483fbd3c@changeid/ Signed-off-by: Aditya Kumar Singh Link: https://patch.msgid.link/20240906064426.2101315-3-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: introduce EHT rate support in AQL airtime

2024-09-06T10:58:36Z

Add definitions related to EHT mode and airtime calculation according to the 802.11BE_D4.0. Co-developed-by: Bo Jiao Signed-off-by: Bo Jiao Signed-off-by: Deren Wu Signed-off-by: Quan Zhou Signed-off-by: Ming Yen Hsieh Link: https://patch.msgid.link/20240904111256.11734-1-mingyen.hsieh@mediatek.com Signed-off-by: Johannes Berg

Merge tag 'wireless-next-2024-09-04' of git://git.kernel.org/pub/scm/linux/kernel/git/wireless/wireless-next

2024-09-05T00:20:14Z

Kalle Valo says: ==================== pull-request: wireless-next-2024-09-04 here's a pull request to net-next tree, more info below. Please let me know if there are any problems. ==================== Conflicts: drivers/net/wireless/ath/ath12k/hw.c 38055789d151 ("wifi: ath12k: use 128 bytes aligned iova in transmit path for WCN7850") 8be12629b428 ("wifi: ath12k: restore ASPM for supported hardwares only") https://lore.kernel.org/87msldyj97.fsf@kernel.org Link: https://patch.msgid.link/20240904153205.64C11C4CEC2@smtp.kernel.org Signed-off-by: Jakub Kicinski