kernel/linux.git/net/mac80211/offchannel.c, branch v6.12.80

wifi: mac80211: don't use rate mask for offchannel TX either

2024-08-27T08:13:23+00:00

Like the commit ab9177d83c04 ("wifi: mac80211: don't use rate mask for scanning"), ignore incorrect settings to avoid no supported rate warning reported by syzbot. The syzbot did bisect and found cause is commit 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band"), which however corrects bitmask of HE MCS and recognizes correctly settings of empty legacy rate plus HE MCS rate instead of returning -EINVAL. As suggestions [1], follow the change of SCAN TX to consider this case of offchannel TX as well. [1] https://lore.kernel.org/linux-wireless/6ab2dc9c3afe753ca6fdcdd1421e7a1f47e87b84.camel@sipsolutions.net/T/#m2ac2a6d2be06a37c9c47a3d8a44b4f647ed4f024 Reported-by: syzbot+8dd98a9e98ee28dc484a@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-wireless/000000000000fdef8706191a3f7b@google.com/ Fixes: 9df66d5b9f45 ("cfg80211: fix default HE tx bitrate mask in 2G band") Signed-off-by: Ping-Ke Shih Link: https://patch.msgid.link/20240729074816.20323-1-pkshih@realtek.com Signed-off-by: Johannes Berg

wifi: mac80211: handle HW restart during ROC

2024-05-29T08:38:53+00:00

If we have a HW restart in the middle of a ROC period, then there are two cases: - if it's a software ROC, we really don't need to do anything, since the ROC work will still be queued and will run later, albeit with the interruption due to the restart; - if it's a hardware ROC, then it may have begun or not, if it did begin already we can only remove it and tell userspace about that. In both cases, this fixes the warning that would appear in ieee80211_start_next_roc() in this case. In the case of some drivers such as iwlwifi, the part of restarting is never going to happen since the driver will cancel the ROC, but flushing the work to ensure nothing is pending here will also result in no longer being able to trigger the warning in this case. Reviewed-by: Miriam Rachel Korenblit Link: https://msgid.link/20240523120352.f1924b5411ea.Ifc02a45a5ce23868dc7e428bad8d0e6996dd10f4@changeid Signed-off-by: Johannes Berg

wifi: mac80211: handle link ID during management Tx

2024-04-19T08:54:58+00:00

During non-STA management Tx, when source address is same as one of the link addresses and even when userspace requested Tx on a specific link, the link ID is not set in the TX control information. Now if the MLD address is also the same as that of the link address, then mac80211 fills link as "unspecified", since it looks like MLD TX. This is unexpected, however, since non-STA TX must specify which link to use. In hwsim, this will (after warnings) result in dropping such frames as well. Use and set the link id if the link bss is matching the address and requested channel. Signed-off-by: Sriram R Signed-off-by: Aditya Kumar Singh Link: https://msgid.link/20240410052705.169865-1-quic_adisi@quicinc.com Link: https://lore.kernel.org/r/0496fb7e-53cc-476f-8052-985d82fd8d01@quicinc.com [reword commit message, should spell out hwsim etc.] Signed-off-by: Johannes Berg

wifi: mac80211: simplify non-chanctx drivers

2024-02-08T11:58:32+00:00

There are still surprisingly many non-chanctx drivers, but in mac80211 that code is a bit awkward. Simplify this by having those drivers assign 'emulated' ops, so that the mac80211 code can be more unified between non-chanctx/chanctx drivers. This cuts the number of places caring about it by about 15, which are scattered across - now they're fewer and no longer in the channel context handling. Link: https://msgid.link/20240129194108.6d0ead50f5cf.I60d093b2fc81ca1853925a4d0ac3a2337d5baa5b@changeid Signed-off-by: Johannes Berg

wifi: mac80211: fix a expired vs. cancel race in roc

2023-10-23T09:45:17+00:00

When the remain on channel is removed at the time it should have expired, we have a race: the driver could be handling the flow of the expiration while mac80211 is cancelling that very same remain on channel request. This wouldn't be problem in itself, but since mac80211 can send the next request to the driver in the cancellation flow, we can get to the following situation: CPU0 CPU1 expiration of roc in driver ieee80211_remain_on_channel_expired() Cancellation of the roc schedules a worker (hw_roc_done) Add next roc hw_roc_done_wk runs and ends the second roc prematurely. Since, by design, there is only one single request sent to the driver at a time, we can safely assume that after the cancel() request returns from the driver, we should not handle any worker that handles the expiration of the request. Cancel the hw_roc_done worker after the cancellation to make sure we start the next one with a clean slate. Signed-off-by: Emmanuel Grumbach Signed-off-by: Gregory Greenman Link: https://lore.kernel.org/r/20230928172905.4e4469be20ac.Iab0525f5cc4698acf23eab98b8b1eec02099cde0@changeid Signed-off-by: Johannes Berg

wifi: mac80211: Do not force off-channel for management Tx with MLO

2023-09-11T10:33:54+00:00

When user space transmits a management frame it is expected to use the MLD addresses if the connection is an MLD one. Thus, in case the management Tx is using the MLD address and no channel is configured off-channel should not be used (as one of the active links would be used). Signed-off-by: Ilan Peer Signed-off-by: Gregory Greenman Link: https://lore.kernel.org/r/20230827135854.73c8efce252f.Ie4b0a842debb24ef25c5e6cb2ad69b9f46bc4b2a@changeid Signed-off-by: Johannes Berg

wifi: cfg80211: remove wdev mutex

2023-09-11T09:27:23+00:00

Since we're now protecting everything with the wiphy mutex (and were really using it for almost everything before), there's no longer any real reason to have a separate wdev mutex. It may feel better, but really has no value. Signed-off-by: Johannes Berg

wifi: mac80211: reduce iflist_mtx

2023-09-11T09:27:22+00:00

We now hold the wiphy mutex everywhere that we use or needed the iflist_mtx, so we don't need this mutex any more in mac80211. However, drivers may also iterate, and in some cases (e.g. mt76) do so from high-priority contexts. Thus, keep the mutex around but remove its usage in mac80211 apart from those driver-visible parts that are still needed. Most of this change was done automatically with spatch, with the parts that are still needed as described above reverted manually. Signed-off-by: Johannes Berg

wifi: mac80211: remove local->mtx

2023-09-11T09:27:22+00:00

We now hold the wiphy mutex everywhere that we use or needed the local->mtx, so we don't need this mutex any more. Remove it. Most of this change was done automatically with spatch. Signed-off-by: Johannes Berg

wifi: mac80211: move dynamic PS to wiphy work

2023-09-11T09:27:20+00:00

Along with everything else, move the dynamic PS work to be a wiphy work, to simplify locking later. Reviewed-by: Emmanuel Grumbach Signed-off-by: Johannes Berg