aboutsummaryrefslogtreecommitdiff
path: root/net
AgeCommit message (Collapse)AuthorFilesLines
2023-09-13tcp: Factorise sk_family-independent comparison in ↵Kuniyuki Iwashima1-15/+13
inet_bind2_bucket_match(_addr_any). This is a prep patch to make the following patches cleaner that touch inet_bind2_bucket_match() and inet_bind2_bucket_match_addr_any(). Both functions have duplicated comparison for netns, port, and l3mdev. Let's factorise them. Signed-off-by: Kuniyuki Iwashima <[email protected]> Reviewed-by: Eric Dumazet <[email protected]> Signed-off-by: David S. Miller <[email protected]>
2023-09-13Merge branch '40GbE' of ↵David S. Miller5-6/+12
git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2023-09-11 (i40e, iavf) This series contains updates to i40e and iavf drivers. Andrii ensures all VSIs are cleaned up for remove in i40e. Brett reworks logic for setting promiscuous mode that can, currently, cause incorrect states on iavf. --- v2: - Remove redundant i40e_vsi_free_q_vectors() and kfree() calls (patch 1) v1: https://lore.kernel.org/netdev/[email protected]/ ==================== Signed-off-by: David S. Miller <[email protected]>
2023-09-12tcp: defer regular ACK while processing socket backlogEric Dumazet4-1/+22
This idea came after a particular workload requested the quickack attribute set on routes, and a performance drop was noticed for large bulk transfers. For high throughput flows, it is best to use one cpu running the user thread issuing socket system calls, and a separate cpu to process incoming packets from BH context. (With TSO/GRO, bottleneck is usually the 'user' cpu) Problem is the user thread can spend a lot of time while holding the socket lock, forcing BH handler to queue most of incoming packets in the socket backlog. Whenever the user thread releases the socket lock, it must first process all accumulated packets in the backlog, potentially adding latency spikes. Due to flood mitigation, having too many packets in the backlog increases chance of unexpected drops. Backlog processing unfortunately shifts a fair amount of cpu cycles from the BH cpu to the 'user' cpu, thus reducing max throughput. This patch takes advantage of the backlog processing, and the fact that ACK are mostly cumulative. The idea is to detect we are in the backlog processing and defer all eligible ACK into a single one, sent from tcp_release_cb(). This saves cpu cycles on both sides, and network resources. Performance of a single TCP flow on a 200Gbit NIC: - Throughput is increased by 20% (100Gbit -> 120Gbit). - Number of generated ACK per second shrinks from 240,000 to 40,000. - Number of backlog drops per second shrinks from 230 to 0. Benchmark context: - Regular netperf TCP_STREAM (no zerocopy) - Intel(R) Xeon(R) Platinum 8481C (Saphire Rapids) - MAX_SKB_FRAGS = 17 (~60KB per GRO packet) This feature is guarded by a new sysctl, and enabled by default: /proc/sys/net/ipv4/tcp_backlog_ack_defer Signed-off-by: Eric Dumazet <[email protected]> Acked-by: Yuchung Cheng <[email protected]> Acked-by: Neal Cardwell <[email protected]> Acked-by: Soheil Hassas Yeganeh <[email protected]> Acked-by: Dave Taht <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-09-12net: call prot->release_cb() when processing backlogEric Dumazet1-0/+3
__sk_flush_backlog() / sk_flush_backlog() are used when TCP recvmsg()/sendmsg() process large chunks, to not let packets in the backlog too long. It makes sense to call tcp_release_cb() to also process actions held in sk->sk_tsq_flags for smoother scheduling. Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-09-12tcp: no longer release socket ownership in tcp_release_cb()Eric Dumazet2-13/+0
This partially reverts c3f9b01849ef ("tcp: tcp_release_cb() should release socket ownership"). prequeue has been removed by Florian in commit e7942d0633c4 ("tcp: remove prequeue support") __tcp_checksum_complete_user() being gone, we no longer have to release socket ownership in tcp_release_cb(). This is a prereq for third patch in the series ("net: call prot->release_cb() when processing backlog"). Signed-off-by: Eric Dumazet <[email protected]> Signed-off-by: Paolo Abeni <[email protected]>
2023-09-12net: dst: remove unnecessary input parameter in dst_alloc and dst_initZhengchao Shao6-15/+15
Since commit 1202cdd66531("Remove DECnet support from kernel") has been merged, all callers pass in the initial_ref value of 1 when they call dst_alloc(). Therefore, remove initial_ref when the dst_alloc() is declared and replace initial_ref with 1 in dst_alloc(). Also when all callers call dst_init(), the value of initial_ref is 1. Therefore, remove the input parameter initial_ref of the dst_init() and replace initial_ref with the value 1 in dst_init. Signed-off-by: Zhengchao Shao <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-09-12net/tls: do not free tls_rec on async operation in bpf_exec_tx_verdict()Liu Jian1-2/+2
I got the below warning when do fuzzing test: BUG: KASAN: null-ptr-deref in scatterwalk_copychunks+0x320/0x470 Read of size 4 at addr 0000000000000008 by task kworker/u8:1/9 CPU: 0 PID: 9 Comm: kworker/u8:1 Tainted: G OE Hardware name: linux,dummy-virt (DT) Workqueue: pencrypt_parallel padata_parallel_worker Call trace: dump_backtrace+0x0/0x420 show_stack+0x34/0x44 dump_stack+0x1d0/0x248 __kasan_report+0x138/0x140 kasan_report+0x44/0x6c __asan_load4+0x94/0xd0 scatterwalk_copychunks+0x320/0x470 skcipher_next_slow+0x14c/0x290 skcipher_walk_next+0x2fc/0x480 skcipher_walk_first+0x9c/0x110 skcipher_walk_aead_common+0x380/0x440 skcipher_walk_aead_encrypt+0x54/0x70 ccm_encrypt+0x13c/0x4d0 crypto_aead_encrypt+0x7c/0xfc pcrypt_aead_enc+0x28/0x84 padata_parallel_worker+0xd0/0x2dc process_one_work+0x49c/0xbdc worker_thread+0x124/0x880 kthread+0x210/0x260 ret_from_fork+0x10/0x18 This is because the value of rec_seq of tls_crypto_info configured by the user program is too large, for example, 0xffffffffffffff. In addition, TLS is asynchronously accelerated. When tls_do_encryption() returns -EINPROGRESS and sk->sk_err is set to EBADMSG due to rec_seq overflow, skmsg is released before the asynchronous encryption process ends. As a result, the UAF problem occurs during the asynchronous processing of the encryption module. If the operation is asynchronous and the encryption module returns EINPROGRESS, do not free the record information. Fixes: 635d93981786 ("net/tls: free record only on encryption error") Signed-off-by: Liu Jian <[email protected]> Reviewed-by: Sabrina Dubroca <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Paolo Abeni <[email protected]>
2023-09-11wifi: cfg80211: fix cqm_config access raceJohannes Berg3-41/+73
Max Schulze reports crashes with brcmfmac. The reason seems to be a race between userspace removing the CQM config and the driver calling cfg80211_cqm_rssi_notify(), where if the data is freed while cfg80211_cqm_rssi_notify() runs it will crash since it assumes wdev->cqm_config is set. This can't be fixed with a simple non-NULL check since there's nothing we can do for locking easily, so use RCU instead to protect the pointer, but that requires pulling the updates out into an asynchronous worker so they can sleep and call back into the driver. Since we need to change the free anyway, also change it to go back to the old settings if changing the settings fails. Reported-and-tested-by: Max Schulze <[email protected]> Closes: https://lore.kernel.org/r/[email protected] Fixes: 4a4b8169501b ("cfg80211: Accept multiple RSSI thresholds for CQM") Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: fix channel switch link dataJohannes Berg2-5/+7
Use the correct link ID and per-link puncturing data instead of hardcoding link ID 0 and using deflink puncturing. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.0b6a211c8e75.I5724d32bb2dae440888efbc47334d8c115db9d50@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: Do not force off-channel for management Tx with MLOIlan Peer1-1/+6
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 <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.73c8efce252f.Ie4b0a842debb24ef25c5e6cb2ad69b9f46bc4b2a@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: take MBSSID/EHT data also from probe respJohannes Berg1-10/+15
The code that sets up the assoc link will currently take the BSS element data from the beacon only. This is correct for some of the data, notably the timing and the "have_beacon", but all the data about MBSSID and EHT really doesn't need to be taken from there, and if the EHT puncturing is misconfigured on the AP but we didn't receive a beacon yet, this causes us to connect but immediately disconnect upon receiving the first beacon, rather than connecting without EHT in the first place. Change the code to take MBSSID and EHT data also from the probe response, for a better picture of what the BSS capabilities are and to avoid that EHT puncturing problem. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.3c7e52d49482.Iba6b672f6dc74b45bba26bc497e953e27da43ef9@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: Print local link address during authenticationIlan Peer1-2/+14
To ease debugging, mostly in cases that authentication fails. Signed-off-by: Ilan Peer <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.9c08605e2691.I0032e9d6e01325862189e4a20b02ddbe8f2f5e75@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: fix # of MSDU in A-MSDU calculationJohannes Berg1-1/+1
During my refactoring I wanted to get rid of the switch, but replaced it with the wrong calculation. Fix that. Fixes: 175ad2ec89fe ("wifi: mac80211: limit A-MSDU subframes for client too") Reported-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.51bf1b8b0adb.Iffbd337fdad2b86ae12f5a39c69fb82b517f7486@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: reg: fix various kernel-doc issuesJohannes Berg1-8/+8
Clean up the kernel-doc comments in reg.h. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.36d7b52da0f5.I85fbfb3095613f4a0512493cbbdda881dc31be2c@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: fix various kernel-doc issuesJohannes Berg2-10/+12
There are various kernel-doc issues here, fix them. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.7ce9761f9ebb.I0f44e76c518f72135cc855c809bfa7a5e977b894@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: remove unnecessary struct forward declarationJohannes Berg1-1/+0
This just causes kernel-doc to complain at this spot, but isn't actually needed anyway, so remove it. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.33a5591dfdeb.If4e7e1a1cb4c04f0afd83db7401c780404dca699@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: add more warnings about inserting sta infoBenjamin Berg1-2/+6
The sta info needs to be inserted before its links may be modified. Add a few warnings to prevent accidental usage of these functions. Signed-off-by: Benjamin Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.eeb43b3cc9e3.I5fd8236f70e64bf6268f33c883f7a878d963b83e@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: add ieee80211_fragment_element to public APIBenjamin Berg3-31/+29
This function will be used by the kunit tests within cfg80211. As it is generally useful, move it from mac80211 to cfg80211. Signed-off-by: Benjamin Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.5af9391659f5.Ie534ed6591ba02be8572d4d7242394f29e3af04b@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: add an element parsing unit testJohannes Berg6-0/+130
Add a unit test for the parsing of a fragmented sta profile sub-element inside a fragmented multi-link element. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.333bc75df13f.I0ddfeb6a88a4d89e7c7850e8ef45a4b19b5a061a@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: add first kunit tests, for element defragJohannes Berg5-0/+182
Add a couple of tests for element defragmentation, to see that the function works correctly. Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.e2a5cead1816.I09f0edc19d162b54ee330991c728c1e9aa42ebf6@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: fix off-by-one in element defragJohannes Berg1-2/+2
If a fragment is the last element, it's erroneously not accepted. Fix that. Fixes: f837a653a097 ("wifi: cfg80211: add element defragmentation helper") Signed-off-by: Johannes Berg <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230827135854.adca9fbd3317.I6b2df45eb71513f3e48efd196ae3cddec362dc1c@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: add support for mld in ieee80211_chswitch_doneEmmanuel Grumbach4-31/+48
This allows to finalize the CSA per link. In case the switch didn't work, tear down the MLD connection. Also pass the ieee80211_bss_conf to post_channel_switch to let the driver know which link completed the switch. Signed-off-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Gregory Greenman <[email protected]> Link: https://lore.kernel.org/r/20230828130311.3d3eacc88436.Ic2d14e2285aa1646216a56806cfd4a8d0054437c@changeid Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: validate AP phy operation before starting itAditya Kumar Singh1-0/+19
Many regulatories can have HE/EHT Operation as not permitted. In such cases, AP should not be allowed to start if it is using a channel having the no operation flag set. However, currently there is no such check in place. Fix this issue by validating such IEs sent during start AP against the channel flags. Signed-off-by: Aditya Kumar Singh <[email protected]> Reviewed-by: Jeff Johnson <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211/mac80211: hold link BSSes when assoc fails for MLO connectionWen Gong2-6/+8
When connect to MLO AP with more than one link, and the assoc response of AP is not success, then cfg80211_unhold_bss() is not called for all the links' cfg80211_bss except the primary link which means the link used by the latest successful association request. Thus the hold value of the cfg80211_bss is not reset to 0 after the assoc fail, and then the __cfg80211_unlink_bss() will not be called for the cfg80211_bss by __cfg80211_bss_expire(). Then the AP always looks exist even the AP is shutdown or reconfigured to another type, then it will lead error while connecting it again. The detail info are as below. When connect with muti-links AP, cfg80211_hold_bss() is called by cfg80211_mlme_assoc() for each cfg80211_bss of all the links. When assoc response from AP is not success(such as status_code==1), the ieee80211_link_data of non-primary link(sdata->link[link_id]) is NULL because ieee80211_assoc_success()->ieee80211_vif_update_links() is not called for the links. Then struct cfg80211_rx_assoc_resp resp in cfg80211_rx_assoc_resp() and struct cfg80211_connect_resp_params cr in __cfg80211_connect_result() will only have the data of the primary link, and finally function cfg80211_connect_result_release_bsses() only call cfg80211_unhold_bss() for the primary link. Then cfg80211_bss of the other links will never free because its hold is always > 0 now. Hence assign value for the bss and status from assoc_data since it is valid for this case. Also assign value of addr from assoc_data when the link is NULL because the addrs of assoc_data and link both represent the local link addr and they are same value for success connection. Fixes: 81151ce462e5 ("wifi: mac80211: support MLO authentication/association with one link") Signed-off-by: Wen Gong <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: fix RCU usage warning in mesh fast-xmitJohannes Berg1-1/+1
In mesh_fast_tx_flush_addr() we already hold the lock, so don't need additional hashtable RCU protection. Use the rhashtable_lookup_fast() variant to avoid RCU protection warnings. Fixes: d5edb9ae8d56 ("wifi: mac80211: mesh fast xmit support") Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: annotate iftype_data pointer with sparseJohannes Berg4-16/+10
There were are a number of cases in mac80211 and iwlwifi (at least) that used the sband->iftype_data pointer directly, instead of using the accessors to find the right array entry to use. Make sparse warn when such a thing is done. To not have a lot of casts, add two helper functions/macros - ieee80211_set_sband_iftype_data() - for_each_sband_iftype_data() Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: fix BA session teardown raceJohannes Berg3-8/+15
As previously reported by Alexander, whose commit 69403bad97aa ("wifi: mac80211: sdata can be NULL during AMPDU start") I'm reverting as part of this commit, there's a race between station destruction and aggregation setup, where the aggregation setup can happen while the station is being removed and queue the work after ieee80211_sta_tear_down_BA_sessions() has already run in __sta_info_destroy_part1(), and thus the worker will run with a now freed station. In his case, this manifested in a NULL sdata pointer, but really there's no guarantee whatsoever. The real issue seems to be that it's possible at all to have a situation where this occurs - we want to stop the BA sessions when doing _part1, but we cannot be sure, and WLAN_STA_BLOCK_BA isn't necessarily effective since we don't know that the setup isn't concurrently running and already got past the check. Simply call ieee80211_sta_tear_down_BA_sessions() again in the second part of station destruction, since at that point really nothing else can hold a reference to the station any more. Also revert the sdata checks since those are just misleading at this point. Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: fix TXQ error path and cleanupJohannes Berg2-2/+3
We currently call ieee80211_txq_teardown_flows() as part of ieee80211_remove_interfaces(), but that's not really right in case of HW registration failures, specifically rate control. Call it separately to fix that issue. Reported-by: Zhengchao Shao <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: remove wdev mutexJohannes Berg30-949/+287
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 <[email protected]>
2023-09-11wifi: mac80211: set wiphy for virtual monitorsJohannes Berg1-0/+1
Drivers might plausibly want to have this, but also the locking assertions will need it later. Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: reduce iflist_mtxJohannes Berg7-42/+29
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 <[email protected]>
2023-09-11wifi: mac80211: remove local->mtxJohannes Berg14-269/+135
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 <[email protected]>
2023-09-11wifi: mac80211: remove ampdu_mlme.mtxJohannes Berg7-117/+60
We now hold the wiphy mutex everywhere that we use or needed the A-MPDU locking, 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 <[email protected]>
2023-09-11wifi: mac80211: remove chanctx_mtxJohannes Berg9-142/+113
We now hold the wiphy mutex everywhere that we use or needed the chanctx_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 <[email protected]>
2023-09-11wifi: mac80211: remove key_mtxJohannes Berg9-132/+90
We now hold the wiphy mutex everywhere that we use or needed the key_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 <[email protected]>
2023-09-11wifi: mac80211: remove sta_mtxJohannes Berg18-214/+112
We now hold the wiphy mutex everywhere that we use or needed the sta_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 <[email protected]>
2023-09-11wifi: mac80211: take wiphy lock for MAC addr changeJohannes Berg1-3/+16
We want to ensure everything holds the wiphy lock, so also extend that to the MAC change callback. Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: extend wiphy lock in interface removalJohannes Berg1-1/+2
We want to extend the wiphy locking to the interface list, so move that into the section locked with the wiphy lock. Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: hold wiphy_lock around concurrency checksJohannes Berg1-2/+3
We want to replace the locking in mac80211 by just the wiphy mutex, so hold the lock here around concurrency checks for the future where the chanctx_mtx used inside goes away. Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: ethtool: hold wiphy mutexJohannes Berg1-2/+6
We should hold the wiphy mutex here since we're going to call the driver and want to remove the sta_mtx. Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: check wiphy mutex is held for wdev mutexJohannes Berg1-1/+7
This might seem pretty pointless rather than changing the locking immediately, but it seems safer to run for a while with checks and the old locking scheme, and then remove the wdev lock later. Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: hold wiphy lock in cfg80211_any_wiphy_oper_chan()Johannes Berg1-3/+7
We have the RTNL here for the iteration, but we need to lock each wiphy separately as well for using its data. Hold the wiphy lock for all of the ones in the iteration. Note that this implies we cannot already hold the wiphy mutex for the wiphy passed by the argument, but that's true now. Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: sme: hold wiphy lock for wdev iterationJohannes Berg1-0/+2
Since we will want to remove the wdev lock in the future, lock the wiphy here to iterate and for checking the status of the connections. Reviewed-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: cfg80211: reg: hold wiphy mutex for wdev iterationJohannes Berg1-0/+3
Since we will want to remove the wdev lock in the future, lock the wiphy here to iterate and check the flags. Reviewed-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: check wiphy mutex in opsJohannes Berg2-0/+95
Check that we hold the wiphy mutex in the ops when calling the driver, since we're now on our way to always hold it, and simplify the locking. Reviewed-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: move color change finalize to wiphy workJohannes Berg4-9/+11
Again this should be per link and will get cancellation issues, move it to a wiphy work. Reviewed-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: move CSA finalize to wiphy workJohannes Berg5-11/+11
This work should be made per link as well, and then will have cancellation issues. Moving it to a wiphy work already fixes those beforehand. Reviewed-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: move filter reconfig to wiphy workJohannes Berg4-6/+7
This again is intended for future cleanups that are possible when mac80211 and drivers can assume the wiphy is locked. Reviewed-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: move tspec work to wiphy workJohannes Berg2-9/+14
One more work that will now execute with the wiphy locked, for future cleanups. Reviewed-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
2023-09-11wifi: mac80211: move key tailroom work to wiphy workJohannes Berg6-11/+17
This way we hold the wiphy mutex there, as a step towards removing some of the additional locks we have. Reviewed-by: Emmanuel Grumbach <[email protected]> Signed-off-by: Johannes Berg <[email protected]>
Powered by cgit, Gruvboxed by Blaster4385.