summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* wifi: mac80211: fix BA session teardown raceJohannes Berg2023-09-113-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 <johannes.berg@intel.com>
* wifi: mac80211_hwsim: fix clang-specific fortify warningDmitry Antipov2023-09-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.ru Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: fix TXQ error path and cleanupJohannes Berg2023-09-112-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 <shaozhengchao@huawei.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: Use flexible array in struct ieee80211_tim_ieJeff Johnson2023-09-111-3/+10
| | | | | | | | | | | | | | | | | | | | | | 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: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230831-ieee80211_tim_ie-v3-2-e10ff584ab5d@quicinc.com [add wifi prefix] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: cfg80211: remove wdev mutexJohannes Berg2023-09-1135-974/+300
| | | | | | | | | 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 <johannes.berg@intel.com>
* wifi: mac80211: set wiphy for virtual monitorsJohannes Berg2023-09-111-0/+1
| | | | | | | Drivers might plausibly want to have this, but also the locking assertions will need it later. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: reduce iflist_mtxJohannes Berg2023-09-117-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 <johannes.berg@intel.com>
* wifi: mac80211: remove local->mtxJohannes Berg2023-09-1114-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 <johannes.berg@intel.com>
* wifi: mac80211: remove ampdu_mlme.mtxJohannes Berg2023-09-117-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 <johannes.berg@intel.com>
* wifi: mac80211: remove chanctx_mtxJohannes Berg2023-09-119-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 <johannes.berg@intel.com>
* wifi: mac80211: remove key_mtxJohannes Berg2023-09-119-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 <johannes.berg@intel.com>
* wifi: mac80211: remove sta_mtxJohannes Berg2023-09-1118-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 <johannes.berg@intel.com>
* wifi: mac80211: take wiphy lock for MAC addr changeJohannes Berg2023-09-111-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 <johannes.berg@intel.com>
* wifi: mac80211: extend wiphy lock in interface removalJohannes Berg2023-09-111-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 <johannes.berg@intel.com>
* wifi: mac80211: hold wiphy_lock around concurrency checksJohannes Berg2023-09-111-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 <johannes.berg@intel.com>
* wifi: mac80211: ethtool: hold wiphy mutexJohannes Berg2023-09-111-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 <johannes.berg@intel.com>
* wifi: cfg80211: check wiphy mutex is held for wdev mutexJohannes Berg2023-09-111-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 <johannes.berg@intel.com>
* wifi: cfg80211: hold wiphy lock in cfg80211_any_wiphy_oper_chan()Johannes Berg2023-09-111-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 <johannes.berg@intel.com>
* wifi: cfg80211: sme: hold wiphy lock for wdev iterationJohannes Berg2023-09-111-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 <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: cfg80211: reg: hold wiphy mutex for wdev iterationJohannes Berg2023-09-111-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 <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: check wiphy mutex in opsJohannes Berg2023-09-112-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 <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move color change finalize to wiphy workJohannes Berg2023-09-114-9/+11
| | | | | | | | Again this should be per link and will get cancellation issues, move it to a wiphy work. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move CSA finalize to wiphy workJohannes Berg2023-09-115-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 <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move filter reconfig to wiphy workJohannes Berg2023-09-114-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 <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move tspec work to wiphy workJohannes Berg2023-09-112-9/+14
| | | | | | | | One more work that will now execute with the wiphy locked, for future cleanups. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move key tailroom work to wiphy workJohannes Berg2023-09-116-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 <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move TDLS work to wiphy workJohannes Berg2023-09-113-10/+12
| | | | | | | Again, to have the wiphy locked for it. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move sched-scan stop work to wiphy workJohannes Berg2023-09-113-8/+10
| | | | | | | | | | 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: a05829a7222e ("cfg80211: avoid holding the RTNL when calling the driver") Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move dynamic PS to wiphy workJohannes Berg2023-09-117-19/+24
| | | | | | | | Along with everything else, move the dynamic PS work to be a wiphy work, to simplify locking later. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move link activation work to wiphy workJohannes Berg2023-09-113-6/+8
| | | | | | | We want to have the wiphy locked for these as well, so move it to be a wiphy work. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move offchannel works to wiphy workJohannes Berg2023-09-113-23/+23
| | | | | | | Make the offchannel works wiphy works to have the wiphy locked for executing them. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: lock wiphy in IP address notifierJohannes Berg2023-09-112-1/+35
| | | | | | | | | | | | 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: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move monitor work to wiphy workJohannes Berg2023-09-112-7/+9
| | | | | | | | Again this serves to simplify the locking in mac80211 in the future, since this is a relatively complex work. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move scan work to wiphy workJohannes Berg2023-09-115-25/+18
| | | | | | | | Move the scan work to wiphy work, which also simplifies the way we handle the work vs. the scan configuration. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move radar detect work to wiphy workJohannes Berg2023-09-113-10/+11
| | | | | | | | Move the radar detect work to wiphy work in order to lock the wiphy for it without doing it manually. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: move DFS CAC work to wiphy workJohannes Berg2023-09-116-15/+16
| | | | | | | | Move the DFS CAC work over to hold the wiphy lock there without worry about work cancellation. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: add more ops assertionsJohannes Berg2023-09-112-0/+36
| | | | | | | | | | | Add more might_sleep() checks and check sdata-in-driver for one additional place. type=feature ticket=jira:WIFI-314309 Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: convert A-MPDU work to wiphy workJohannes Berg2023-09-116-17/+15
| | | | | | | | | | | Convert the A-MPDU work to wiphy work so it holds the wiphy mutex and we can later guarantee that to drivers. It might seem that we could run these concurrently for different stations, but they're all on the ordered mac80211 workqueue, so this shouldn't matter for that. Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: flush wiphy work where appropriateJohannes Berg2023-09-112-0/+2
| | | | | | | | | Before converting more works to wiphy work, add flushing in mac80211 where we also flush the mac80211 workqueue. Not needed in suspend since cfg80211 will have taken care of it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: cfg80211: add flush functions for wiphy workJohannes Berg2023-09-114-5/+57
| | | | | | | | There may be sometimes reasons to actually run the work if it's pending, add flush functions for both regular and delayed wiphy work that will do this. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: cfg80211: check RTNL when iterating devicesJohannes Berg2023-09-116-17/+27
| | | | | | | Add a new "for_each_rdev()" macro and check that we hold the RTNL when calling it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: lock wiphy for aggregation debugfsJohannes Berg2023-09-111-1/+3
| | | | | | | To change aggregation status may call into the driver, lock the wiphy for this. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: hold wiphy lock in netdev/link debugfsJohannes Berg2023-09-111-33/+90
| | | | | | | | | | | It's no longer really needed to ensure that the debugfs file isn't going away, debugfs handles that. So there's no point in holding dev_base_lock or RTNL here, but we should instead hold the wiphy lock since drivers will be allowed to depend on that. Do that, which requires splitting the sdata and link macros a bit. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: debugfs: lock wiphy instead of RTNLJohannes Berg2023-09-111-3/+3
| | | | | | | | | | Since we no longer really use the RTNL, there's no point in locking it here. Most drivers don't really need to have any locks here anyway, and the rest are probably completely broken, but it's a debugfs-only callback so it really doesn't matter much. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: fix SMPS status handlingJohannes Berg2023-09-115-50/+78
| | | | | | | | | | | | | | | | | The current SMPS status handling isn't per link, so we only ever change the deflink, which is obviously wrong, it's not even used for multi-link connections, but the request API actually includes the link ID. Use the new status_data changes to move the handling to the right link, this also saves parsing the frame again on the status report, instead we can now check only if it was an SMPS frame. Of course, move the worker to be a wiphy work so that we're able to cancel it safely for the link. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: Fix SMPS handling in the context of MLOIlan Peer2023-09-113-5/+11
| | | | | | | | | | | | | | When the connection is a MLO connection, a SMPS request should be sent on a specific link, as SMPS is BSS specific, and the DA and BSSID used for the action frame transmission should be the AP MLD address, as the underlying driver is expected to perform the address translation (based on the link ID). Fix the SMPS request handling to use the AP MLD address and provide the link ID for the request processing during Tx. Signed-off-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: rework ack_frame_id handling a bitJohannes Berg2023-09-115-10/+25
| | | | | | | | | | | Take one more free bit to indicate it's IDR vs. internal usage, to be able to carve out some bits here for other internal usage, other than IDR handling with a full ACK SKB, that is. Reviewed-by: Benjamin Berg <benjamin.berg@intel.com> Reviewed-by: Ilan Peer <ilan.peer@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* wifi: mac80211: tx: clarify conditions in if statementJohannes Berg2023-09-111-3/+4
| | | | | | | This really just reformats the statement, but makes it more readable. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* ssb: Fix division by zero issue in ssb_calc_clock_rateRand Deeb2023-09-071-1/+1
| | | | | | | | | | | | | | | | | | | In ssb_calc_clock_rate(), there is a potential issue where the value of m1 could be zero due to initialization using clkfactor_f6_resolv(). This situation raised concerns about the possibility of a division by zero error. We fixed it by following the suggestions provided by Larry Finger <Larry.Finger@lwfinger.net> and Michael Büsch <m@bues.ch>. The fix involves returning a value of 1 instead of 0 in clkfactor_f6_resolv(). This modification ensures the proper functioning of the code and eliminates the risk of division by zero errors. Signed-off-by: Rand Deeb <rand.sec96@gmail.com> Acked-by: Larry Finger <Larry.Finger@lwfinger.net> Acked-by: Michael Büsch <m@bues.ch> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230904232346.34991-1-rand.sec96@gmail.com
* wifi: rtw89: 8922a: set memory heap address for secure firmwarePing-Ke Shih2023-09-072-0/+6
| | | | | | | | | | Secure firmware is protected by public/private key cryptography. To help firmware self verify integrity, configure a heap address for these data before downloading firmware. Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/20230901073956.54203-9-pkshih@realtek.com
generated by cgit v1.2.3 (git 2.39.1) at 2025-01-23 22:40:55 +0100