- 11 Sep, 2023 40 commits
-
-
Benjamin Berg authored
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 <benjamin.berg@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230827135854.eeb43b3cc9e3.I5fd8236f70e64bf6268f33c883f7a878d963b83e@changeidSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
Benjamin Berg authored
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:
-
Johannes Berg authored
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 authored
Add a couple of tests for element defragmentation, to see that the function works correctly. Signed-off-by:
-
Johannes Berg authored
If a fragment is the last element, it's erroneously not accepted. Fix that. Fixes: f837a653 ("wifi: cfg80211: add element defragmentation helper") Signed-off-by:
-
Emmanuel Grumbach authored
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 <emmanuel.grumbach@intel.com> Signed-off-by:
-
Johannes Berg authored
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: d5edb9ae ("wifi: mac80211: mesh fast xmit support") Signed-off-by:
-
Johannes Berg authored
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 authored
As previously reported by Alexander, whose commit 69403bad ("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:
-
Dmitry Antipov authored
When compiling with clang 16.0.6 and CONFIG_FORTIFY_SOURCE=y, I've noticed the following (somewhat confusing due to absence of an actual source code location): In file included from drivers/net/wireless/virtual/mac80211_hwsim.c:18: In file included from ./include/linux/slab.h:16: In file included from ./include/linux/gfp.h:7: In file included from ./include/linux/mmzone.h:8: In file included from ./include/linux/spinlock.h:56: In file included from ./include/linux/preempt.h:79: In file included from ./arch/x86/include/asm/preempt.h:9: In file included from ./include/linux/thread_info.h:60: In file included from ./arch/x86/include/asm/thread_info.h:53: In file included from ./arch/x86/include/asm/cpufeature.h:5: In file included from ./arch/x86/include/asm/processor.h:23: In file included from ./arch/x86/include/asm/msr.h:11: In file included from ./arch/x86/include/asm/cpumask.h:5: In file included from ./include/linux/cpumask.h:12: In file included from ./include/linux/bitmap.h:11: In file included from ./include/linux/string.h:254: ./include/linux/fortify-string.h:592:4: warning: call to '__read_overflow2_field' declared with 'warning' attribute: detected read beyond size of field (2nd parameter); maybe use struct_group()? [-Wattribute-warning] __read_overflow2_field(q_size_field, size); The compiler actually complains on 'mac80211_hwsim_get_et_strings()' where fortification logic inteprets call to 'memcpy()' as an attempt to copy the whole 'mac80211_hwsim_gstrings_stats' array from its first member and so issues an overread warning. This warning may be silenced by passing an address of the whole array and not the first member to 'memcpy()'. Signed-off-by:Dmitry Antipov <dmantipov@yandex.ru> Link: https://lore.kernel.org/r/20230829094140.234636-1-dmantipov@yandex.ruSigned-off-by:
-
Johannes Berg authored
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 <shaozhengchao@huawei.com> Signed-off-by:
-
Jeff Johnson authored
Currently struct ieee80211_tim_ie defines: u8 virtual_map[1]; Per the guidance in [1] change this to be a flexible array. Per the discussion in [2] wrap the virtual_map in a union with a u8 item in order to preserve the existing expectation that the virtual_map must contain at least one octet (at least when used in a non-S1G PPDU). This means that no driver changes are required. [1] https://docs.kernel.org/process/deprecated.html#zero-length-and-one-element-arrays [2] https://lore.kernel.org/linux-wireless/202308301529.AC90A9EF98@keescook/Suggested-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Jeff Johnson <quic_jjohnson@quicinc.com> Reviewed-by:
-
Johannes Berg authored
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 authored
Drivers might plausibly want to have this, but also the locking assertions will need it later. Signed-off-by: -
Johannes Berg authored
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 authored
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 authored
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 authored
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 authored
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 authored
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 authored
We want to ensure everything holds the wiphy lock, so also extend that to the MAC change callback. Signed-off-by: -
Johannes Berg authored
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 authored
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 authored
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 authored
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 authored
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 authored
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:
-
Johannes Berg authored
Since we will want to remove the wdev lock in the future, lock the wiphy here to iterate and check the flags. Reviewed-by:
-
Johannes Berg authored
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:
-
Johannes Berg authored
Again this should be per link and will get cancellation issues, move it to a wiphy work. Reviewed-by:
-
Johannes Berg authored
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:
-
Johannes Berg authored
This again is intended for future cleanups that are possible when mac80211 and drivers can assume the wiphy is locked. Reviewed-by:
-
Johannes Berg authored
One more work that will now execute with the wiphy locked, for future cleanups. Reviewed-by:
-
Johannes Berg authored
This way we hold the wiphy mutex there, as a step towards removing some of the additional locks we have. Reviewed-by:
-
Johannes Berg authored
Again, to have the wiphy locked for it. Reviewed-by:
-
Johannes Berg authored
This also has the wiphy locked here then. We need to use the _locked version of cfg80211_sched_scan_stopped() now, which also fixes an old deadlock there. Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") Reviewed-by:
-
Johannes Berg authored
Along with everything else, move the dynamic PS work to be a wiphy work, to simplify locking later. Reviewed-by:
-
Johannes Berg authored
We want to have the wiphy locked for these as well, so move it to be a wiphy work. Signed-off-by: -
Johannes Berg authored
Make the offchannel works wiphy works to have the wiphy locked for executing them. Signed-off-by: -
Johannes Berg authored
Lock the wiphy in the IP address notifier as another place that should have it locked before calling into the driver. This needs a bit of attention since the notifier can be called while the wiphy is already locked, when we remove an interface. Handle this by not running the notifier in this case, and instead calling out to the driver directly. Signed-off-by:
-
