- 14 Jun, 2023 1 commit
-
-
Hugh Dickins authored
Lockdep on 6.4-rc on ThinkPad X1 Carbon 5th says ===================================================== WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected 6.4.0-rc5 #1 Not tainted ----------------------------------------------------- kworker/3:1/49 [HC0[0]:SC0[4]:HE1:SE0] is trying to acquire: ffff8881066fa368 (&mvm_sta->deflink.lq_sta.rs_drv.pers.lock){+.+.}-{2:2}, at: rs_drv_get_rate+0x46/0xe7 and this task is already holding: ffff8881066f80a8 (&sta->rate_ctrl_lock){+.-.}-{2:2}, at: rate_control_get_rate+0xbd/0x126 which would create a new lock dependency: (&sta->rate_ctrl_lock){+.-.}-{2:2} -> (&mvm_sta->deflink.lq_sta.rs_drv.pers.lock){+.+.}-{2:2} but this new dependency connects a SOFTIRQ-irq-safe lock: (&sta->rate_ctrl_lock){+.-.}-{2:2} etc. etc. etc. Changing the spin_lock() in rs_drv_get_rate() to spin_lock_bh() was not enough to pacify lockdep, but changing them all on pers.lock has worked. Fixes: a8938bc8 ("wifi: iwlwifi: mvm: Add locking to the rate read flow") Signed-off-by:Hugh Dickins <hughd@google.com> Link: https://lore.kernel.org/r/79ffcc22-9775-cb6d-3ffd-1a517c40beef@google.comSigned-off-by:
Johannes Berg <johannes.berg@intel.com>
-
- 12 Jun, 2023 1 commit
-
-
Benjamin Berg authored
When fragmenting the ML per STA profile, the element ID should be IEEE80211_MLE_SUBELEM_PER_STA_PROFILE rather than WLAN_EID_FRAGMENT. Change the helper function to take the to be used element ID and pass the appropriate value for each of the fragmentation levels. Fixes: 81151ce4 ("wifi: mac80211: support MLO authentication/association with one link") Signed-off-by:
Benjamin Berg <benjamin.berg@intel.com> Signed-off-by:
Gregory Greenman <gregory.greenman@intel.com> Link: https://lore.kernel.org/r/20230611121219.9b5c793d904b.I7dad952bea8e555e2f3139fbd415d0cd2b3a08c3@changeidSigned-off-by:
-
- 09 Jun, 2023 6 commits
-
-
Ilan Peer authored
Fix few places on the Tx path where the valid_links were used instead of active links. Signed-off-by:
Ilan Peer <ilan.peer@intel.com> Signed-off-by:
-
Johannes Berg authored
Since links are only controlled by userspace via cfg80211 in AP mode, also only remove them from the driver in that case. Signed-off-by:
-
Benjamin Berg authored
ieee80211_vif_set_links requires the sdata->local->mtx lock to be held. Add the appropriate locking around the calls in both the link add and remove handlers. This causes a warning when e.g. ieee80211_link_release_channel is called via ieee80211_link_stop from ieee80211_vif_update_links. Fixes: 0d8c4a3c ("wifi: mac80211: implement add/del interface link callbacks") Signed-off-by:
-
Benjamin Berg authored
The wrapper function was incorrectly calling the add handler instead of the del handler. This had no negative side effect as the default handlers are essentially identical. Fixes: f2a0290b ("wifi: cfg80211: add optional link add/remove callbacks") Signed-off-by:
-
Johannes Berg authored
In the normal MLME code we always call ieee80211_mgd_set_link_qos_params() before ieee80211_link_info_change_notify() and some drivers, notably iwlwifi, rely on that as they don't do anything (but store the data) in their conf_tx. Fix the order here to be the same as in the normal code paths, so this isn't broken. Fixes: 3d901102 ("wifi: mac80211: implement link switching") Signed-off-by:
-
Dan Carpenter authored
The locking was changed recently so now the caller holds the wiphy_lock() lock. Taking the lock inside the reg_wdev_chan_valid() function will lead to a deadlock. Fixes: f7e60032 ("wifi: cfg80211: fix locking in regulatory disconnect") Signed-off-by:
Dan Carpenter <dan.carpenter@linaro.org> Link: https://lore.kernel.org/r/40c4114a-6cb4-4abf-b013-300b598aba65@moroto.mountainSigned-off-by:
-
- 06 Jun, 2023 8 commits
-
-
Johannes Berg authored
This should use wiphy_lock() now instead of requiring the RTNL, since __cfg80211_leave() via cfg80211_leave() is now requiring that lock to be held. Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") Signed-off-by:
-
Johannes Berg authored
This should use wiphy_lock() now instead of acquiring the RTNL, since cfg80211_stop_sched_scan_req() now needs that. Fixes: a05829a7 ("cfg80211: avoid holding the RTNL when calling the driver") Signed-off-by:
-
Gustavo A. R. Silva authored
kmemdup() at line 2735 is not duplicating enough memory for notif->tid_tear_down and notif->station_id. As it only duplicates 612 bytes: up to offsetofend(struct iwl_wowlan_info_notif, received_beacons), this is the range of [0, 612) bytes. 2735 notif = kmemdup(notif_v1, 2736 offsetofend(struct iwl_wowlan_info_notif, 2737 received_beacons), 2738 GFP_ATOMIC); which evidently does not cover bytes 612 and 613 for members tid_tear_down and station_id in struct iwl_wowlan_info_notif. See below: $ pahole -C iwl_wowlan_info_notif drivers/net/wireless/intel/iwlwifi/mvm/d3.o struct iwl_wowlan_info_notif { struct iwl_wowlan_gtk_status_v3 gtk[2]; /* 0 488 */ /* --- cacheline 7 boundary (448 bytes) was 40 bytes ago --- */ struct iwl_wowlan_igtk_status igtk[2]; /* 488 80 */ /* --- cacheline 8 boundary (512 bytes) was 56 bytes ago --- */ __le64 replay_ctr; /* 568 8 */ /* --- cacheline 9 boundary (576 bytes) --- */ __le16 pattern_number; /* 576 2 */ __le16 reserved1; /* 578 2 */ __le16 qos_seq_ctr[8]; /* 580 16 */ __le32 wakeup_reasons; /* 596 4 */ __le32 num_of_gtk_rekeys; /* 600 4 */ __le32 transmitted_ndps; /* 604 4 */ __le32 received_beacons; /* 608 4 */ u8 tid_tear_down; /* 612 1 */ u8 station_id; /* 613 1 */ u8 reserved2[2]; /* 614 2 */ /* size: 616, cachelines: 10, members: 13 */ /* last cacheline: 40 bytes */ }; Therefore, when the following assignments take place, actually no memory has been allocated for those objects: 2743 notif->tid_tear_down = notif_v1->tid_tear_down; 2744 notif->station_id = notif_v1->station_id; Fix this by allocating space for the whole notif object and zero out the remaining space in memory after member station_id. This also fixes the following -Warray-bounds issues: CC drivers/net/wireless/intel/iwlwifi/mvm/d3.o drivers/net/wireless/intel/iwlwifi/mvm/d3.c: In function ‘iwl_mvm_wait_d3_notif’: drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2743:30: warning: array subscript ‘struct iwl_wowlan_info_notif[0]’ is partly outside array bounds of ‘unsigned char[612]’ [-Warray-bounds=] 2743 | notif->tid_tear_down = notif_v1->tid_tear_down; | from drivers/net/wireless/intel/iwlwifi/mvm/d3.c:7: In function ‘kmemdup’, inlined from ‘iwl_mvm_wait_d3_notif’ at drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2735:12: include/linux/fortify-string.h:765:16: note: object of size 612 allocated by ‘__real_kmemdup’ 765 | return __real_kmemdup(p, size, gfp); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ drivers/net/wireless/intel/iwlwifi/mvm/d3.c: In function ‘iwl_mvm_wait_d3_notif’: drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2744:30: warning: array subscript ‘struct iwl_wowlan_info_notif[0]’ is partly outside array bounds of ‘unsigned char[612]’ [-Warray-bounds=] 2744 | notif->station_id = notif_v1->station_id; | ^~ In function ‘kmemdup’, inlined from ‘iwl_mvm_wait_d3_notif’ at drivers/net/wireless/intel/iwlwifi/mvm/d3.c:2735:12: include/linux/fortify-string.h:765:16: note: object of size 612 allocated by ‘__real_kmemdup’ 765 | return __real_kmemdup(p, size, gfp); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ Link: https://github.com/KSPP/linux/issues/306 Fixes: 905d50dd ("wifi: iwlwifi: mvm: support wowlan info notification version 2") Cc: stable@vger.kernel.org Signed-off-by:Gustavo A. R. Silva <gustavoars@kernel.org> Acked-by:
-
Aditya Kumar Singh authored
Currently, whenever an EMA beacon is formed, due to is_template argument being false from the caller, the switch count is always decremented once which is wrong. Also if switch count is equal to profile periodicity, this makes the switch count to reach till zero which triggers a WARN_ON_ONCE. [ 261.593915] CPU: 1 PID: 800 Comm: kworker/u8:3 Not tainted 5.4.213 #0 [ 261.616143] Hardware name: Qualcomm Technologies, Inc. IPQ9574 [ 261.622666] Workqueue: phy0 ath12k_get_link_bss_conf [ath12k] [ 261.629771] pstate: 60400005 (nZCv daif +PAN -UAO) [ 261.635595] pc : ieee80211_next_txq+0x1ac/0x1b8 [mac80211] [ 261.640282] lr : ieee80211_beacon_update_cntdwn+0x64/0xb4 [mac80211] [...] [ 261.729683] Call trace: [ 261.734986] ieee80211_next_txq+0x1ac/0x1b8 [mac80211] [ 261.737156] ieee80211_beacon_cntdwn_is_complete+0xa28/0x1194 [mac80211] [ 261.742365] ieee80211_beacon_cntdwn_is_complete+0xef4/0x1194 [mac80211] [ 261.749224] ieee80211_beacon_get_template_ema_list+0x38/0x5c [mac80211] [ 261.755908] ath12k_get_link_bss_conf+0xf8/0x33b4 [ath12k] [ 261.762590] ath12k_get_link_bss_conf+0x390/0x33b4 [ath12k] [ 261.767881] process_one_work+0x194/0x270 [ 261.773346] worker_thread+0x200/0x314 [ 261.777514] kthread+0x140/0x150 [ 261.781158] ret_from_fork+0x10/0x18 Fix this issue by making the is_template argument as true when fetching the EMA beacons. Fixes: bd54f3c2 ("wifi: mac80211: generate EMA beacons in AP mode") Signed-off-by:
Aditya Kumar Singh <quic_adisi@quicinc.com> Link: https://lore.kernel.org/r/20230531062012.4537-1-quic_adisi@quicinc.comSigned-off-by:
-
Johannes Berg authored
Don't do link address translation for beacons and probe responses, this leads to reporting multiple scan list entries for the same AP (one with the MLD address) which just breaks things. We might need to extend this in the future for some other (action) frames that aren't MLD addressed. Fixes: 42fb9148 ("wifi: mac80211: do link->MLD address translation on RX") Signed-off-by:
-
Johannes Berg authored
There were two bugs when creating the non-inheritence element: 1) 'at_extension' needs to be declared outside the loop, otherwise the value resets every iteration and we can never really switch properly 2) 'added' never got set to true, so we always cut off the extension element again at the end of the function This shows another issue that we might add a list but no extension list, but we need to make the extension list a zero-length one in that case. Fix all these issues. While at it, add a comment explaining the trim. Fixes: 81151ce4 ("wifi: mac80211: support MLO authentication/association with one link") Signed-off-by: -
Johannes Berg authored
When trying to authenticate, if the AP MLD address isn't a valid address, mac80211 can throw a warning. Avoid that by rejecting such addresses. Fixes: d648c230 ("wifi: nl80211: support MLO in auth/assoc") Signed-off-by:
-
Johannes Berg authored
We already check that the right iftype capa exists, but then don't use it. Assign it to a variable so we can actually use it, and then do that. Fixes: bac2fd3d ("mac80211: remove use of ieee80211_get_he_sta_cap()") Signed-off-by:
-
- 01 Jun, 2023 4 commits
-
-
Lorenzo Bianconi authored
Fix possible NULL pointer dereference on mvif pointer in mt7996_mac_write_txwi routine. Fixes: 15ee62e7 ("wifi: mt76: mt7996: enable BSS_CHANGED_BASIC_RATES support") Signed-off-by:
Lorenzo Bianconi <lorenzo@kernel.org> Reviewed-by:
Simon Horman <simon.horman@corigine.com> Signed-off-by:
Kalle Valo <kvalo@kernel.org> Link: https://lore.kernel.org/r/2637628a84f42ad6d7b774e706f041d5b45c8cb5.1685269638.git.lorenzo@kernel.org
-
Ping-Ke Shih authored
Originally, add this check rule to prevent entering LPS if more than one vif (in station mode) connect to AP. Since we have checked this by previous commit, remove this redundant check. Signed-off-by:
Ping-Ke Shih <pkshih@realtek.com> Signed-off-by:
-
Ping-Ke Shih authored
This driver relies on IEEE80211_CONF_PS of hw->conf.flags to turn off PS or turn on dynamic PS controlled by driver and firmware. Though this would be incorrect, it did work before because the flag is always recalculated until the commit 28977e79 ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS") is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS of hw->conf.flags if driver sets SUPPORTS_DYNAMIC_PS. Correct this by doing recalculation while BSS_CHANGED_PS is changed and interface is added or removed. For now, it is allowed to enter PS only if single one station vif is working, and it could possible to have PS per vif after firmware can support it. Without this fix, driver doesn't enter PS anymore that causes higher power consumption. Fixes: e3ec7017 ("rtw89: add Realtek 802.11ax driver") Cc: stable@vger.kernel.org # 6.1+ Signed-off-by:
-
Ping-Ke Shih authored
This driver relies on IEEE80211_CONF_PS of hw->conf.flags to turn off PS or turn on dynamic PS controlled by driver and firmware. Though this would be incorrect, it did work before because the flag is always recalculated until the commit 28977e79 ("wifi: mac80211: skip powersave recalc if driver SUPPORTS_DYNAMIC_PS") is introduced by kernel 5.20 to skip to recalculate IEEE80211_CONF_PS of hw->conf.flags if driver sets SUPPORTS_DYNAMIC_PS. Correct this by doing recalculation while BSS_CHANGED_PS is changed and interface is added or removed. It is allowed to enter PS only if single one station vif is working. Without this fix, driver doesn't enter PS anymore that causes higher power consumption. Fixes: bcde60e5 ("rtw88: remove misleading module parameter rtw_fw_support_lps") Cc: stable@vger.kernel.org # 6.1+ Signed-off-by:
-
- 27 May, 2023 1 commit
-
-
Lorenzo Bianconi authored
Grab sta_poll_lock spinlock in mt7615_mac_sta_poll routine in order to avoid possible races with mt7615_mac_add_txs() or mt7615_mac_fill_rx() removing msta pointer from sta_poll_list. Fixes: a621372a ("mt76: mt7615: rework mt7615_mac_sta_poll for usb code") Signed-off-by:
-
- 17 May, 2023 2 commits
-
-
Arnd Bergmann authored
clang warns about an unpacked structure inside of a packed one: drivers/net/wireless/broadcom/b43/b43.h:654:4: error: field data within 'struct b43_iv' is less aligned than 'union (unnamed union at /home/arnd/arm-soc/drivers/net/wireless/broadcom/b43/b43.h:651:2)' and is usually due to 'struct b43_iv' being packed, which can lead to unaligned accesses [-Werror,-Wunaligned-access] The problem here is that the anonymous union has the default alignment from its members, apparently because the original author mixed up the placement of the __packed attribute by placing it next to the struct member rather than the union definition. As the struct itself is also marked as __packed, there is no need to mark its members, so just move the annotation to the inner type instead. As Michael noted, the same problem is present in b43legacy, so change both at the same time. Acked-by:
Michael Büsch <m@bues.ch> Reported-by:
kernel test robot <lkp@intel.com> Reviewed-by:
Larry Finger <Larry.Finger@lwfinger.net> Link: https://lore.kernel.org/oe-kbuild-all/202305160749.ay1HAoyP-lkp@intel.com/Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Martin Blumenstingl authored
The Allwinner sunxi-mmc controller cannot handle word (16 bit) transfers. So and sdio_{read,write}w fails with messages like the following example using an RTL8822BS (but the same problems were also observed with RTL8822CS and RTL8723DS chips): rtw_8822bs mmc1:0001:1: Firmware version 27.2.0, H2C version 13 sunxi-mmc 4021000.mmc: unaligned scatterlist: os f80 length 2 sunxi-mmc 4021000.mmc: map DMA failed rtw_8822bs mmc1:0001:1: sdio read16 failed (0x10230): -22 Use two consecutive single byte accesses for word operations instead. It turns out that upon closer inspection this is also what the vendor driver does, even though it does have support for sdio_{read,write}w. So we can conclude that the rtw88 chips do support word access but only on SDIO controllers that also support it. Since there's no way to detect if the controller supports word access or not the rtw88 sdio driver switches to the easiest approach: avoiding word access. Reported-by:Rudi Heitbaum <rudi@heitbaum.com> Link: https://github.com/LibreELEC/LibreELEC.tv/pull/7837#issue-1708469467 Fixes: 65371a3f ("wifi: rtw88: sdio: Add HCI implementation for SDIO based chipsets") Reviewed-by:
Martin Blumenstingl <martin.blumenstingl@googlemail.com> Signed-off-by:
-
- 16 May, 2023 17 commits
-
-
Zhengchao Shao authored
When parse_pmsr_capa failed in hwsim_new_radio_nl, the memory resources applied for by pmsr_capa are not released. Add release processing to the incorrect path. Fixes: 92d13386 ("mac80211_hwsim: add PMSR capability support") Reported-by: syzbot+904ce6fbb38532d9795c@syzkaller.appspotmail.com Signed-off-by:
Zhengchao Shao <shaozhengchao@huawei.com> Reviewed-by:
-
Ariel Malamud authored
The rs_drv_get_rate flow reads the lq_sta to return the optimal rate for tx frames. This read flow is not protected thereby leaving a small window, a few instructions wide, open to contention by an asynchronous rate update. Indeed this race condition was hit and the update occurred in the middle of the read. Fix this by locking the lq_sta struct during read. Signed-off-by:
Ariel Malamud <ariel.malamud@intel.com> Signed-off-by:
-
Miri Korenblit authored
This bitmap equals to zero when in a non-MLO mode, and then we won't be iterating on any link. Use for_each_sta_active_link() instead, as it handles also the case of non-MLO mode. Signed-off-by:
Miri Korenblit <miriam.rachel.korenblit@intel.com> Signed-off-by:
-
Johannes Berg authored
If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response. Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictly. Fixes: dcaf9f5e ("iwlwifi: mvm: add MCC update FW API") Signed-off-by:
-
Alon Giladi authored
Fix a spelling mistake. Fixes: 2856f623 ("iwlwifi: mvm: Add list of OEMs allowed to use TAS") Signed-off-by:
Alon Giladi <alon.giladi@intel.com> Signed-off-by:
-
Alon Giladi authored
Fix a spelling mistake. Fixes: e8e10a37 ("iwlwifi: acpi: move ppag code from mvm to fw/acpi") Signed-off-by:
-
Mukesh Sisodiya authored
In iwl_mvm_mld_update_sta(), if the flow doesn't enter for_each_sta_active_link(), the default value is returned. Set this default to -EINVAL instead of 0 to better reflect this. Signed-off-by:
Mukesh Sisodiya <mukesh.sisodiya@intel.com> Signed-off-by:
-
Gregory Greenman authored
RCU protected fw_id_to_mac_id can be initialized with either an error code or NULL. Thus, after dereferencing need to check the value with IS_ERR_OR_NULL() and not only that it is not NULL. Fix it. Signed-off-by:
-
Johannes Berg authored
The DBGI dump is (unsurprisingly) of type DBGI, not SRAM. This leads to bad register accesses because the union is built differently, there's no allocation ID, and thus the allocation ID ends up being 0x8000. Note that this was already wrong for DRAM vs. SMEM since they use different parts of the union, but the allocation ID is at the same place, so it worked. Fix all of this but set the allocation ID in a way that the offset calculation ends up without any offset. Fixes: 34bc2778 ("iwlwifi: yoyo: fix DBGI_SRAM ini dump header.") Signed-off-by:
-
Johannes Berg authored
The concurrent link checks need to correctly differentiate between AP and non-AP, fix that. Signed-off-by:
-
Johannes Berg authored
Lockdep points out that we can deadlock here by calling cancel_delayed_work_sync() because that might be already running and gotten interrupted by the NAPI soft-IRQ. Even just calling something that can sleep is wrong in this context though. Luckily, it doesn't even really matter since the things we need to do are idempotent, so just drop the _sync(). Fixes: e5d153ec ("iwlwifi: mvm: fix CSA AP side") Signed-off-by:
-
Johannes Berg authored
We don't need to (and shouldn't) initialize the spinlock during HW restart that was already initialized, so move that into the correct if block. Since then we have two consecutive if statements with the same (though inverted) condition, unify those as well. Signed-off-by:
-
Johannes Berg authored
There are some assertions in the STA removal code that can fail, and in that case we may leak memory since we skip the freeing. Fix this by freeing the dup_data earlier in the function, we already have a check for when we free the station, and this we don't need to do it with and without MLD API, so it's a win all around. Fixes: a571f5f6 ("iwlwifi: mvm: add duplicate packet detection per rx queue") Signed-off-by:
-
Johannes Berg authored
When we allocate a new channel context, or find an existing one that is compatible, we currently assign it to a link before its mindef is updated. This leads to strange situations, especially in link switching where you switch to an 80 MHz link and expect it to be active immediately, but the mindef is still configured to 20 MHz while assigning. Also, it's strange that the chandef passed to the assign method's argument is wider than the one in the context. Fix this by calculating the mindef with the new link considered before calling the driver. In particular, this fixes an iwlwifi problem during link switch where the firmware would assert because the (link) station that was added for the AP is configured to transmit at a bandwidth that's wider than the channel context that it's configured on. Signed-off-by:
-
Johannes Berg authored
When a chanctx is reserved for a new vif and we recalculate the minimal definition for it, we need to consider the new interface it's being reserved for before we assign it, so it can be used directly with the correct min channel width. Fix the code to - optionally - consider that, and use that option just before doing the reassignment. Also, when considering channel context reservations, we should only consider the one link we're currently working with. Change the boolean argument to a link pointer to do that. Signed-off-by:
-
Johannes Berg authored
There's no need to call ieee80211_recalc_chanctx_min_def() since it cannot and won't call the driver anyway; just use _ieee80211_recalc_chanctx_min_def() instead. Signed-off-by:
-
Michael Lee authored
When stopping the AP, there might be a color change in progress. It should be deactivated here, or the driver might later finalize a color change on a stopped AP. Fixes: 5f9404ab (mac80211: add support for BSS color change) Signed-off-by:
Michael Lee <michael-cy.lee@mediatek.com> Link: https://lore.kernel.org/r/20230504080441.22958-1-michael-cy.lee@mediatek.comSigned-off-by:
-
