summaryrefslogtreecommitdiffstats
path: root/net/mac80211/rate.c (follow)
Commit message (Collapse)AuthorAgeFilesLines
* wifi: mac80211: move some future per-link data to bss_confJohannes Berg2022-06-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | To add MLD, reuse the bss_conf structure later for per-link information, so move some things into it that are per link. Most transformations were done with the following spatch: @@ expression sdata; identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color }; @@ -sdata->vif.var +sdata->vif.bss_conf.var @@ struct ieee80211_vif *vif; identifier var = { chanctx_conf, mu_mimo_owner, csa_active, color_change_active, color_change_color }; @@ -vif->var +vif->bss_conf.var Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: prepare sta handling for MLO supportSriram R2022-04-111-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently in mac80211 each STA object is represented using sta_info datastructure with the associated STA specific information and drivers access ieee80211_sta part of it. With MLO (Multi Link Operation) support being added in 802.11be standard, though the association is logically with a single Multi Link capable STA, at the physical level communication can happen via different advertised links (uniquely identified by Channel, operating class, BSSID) and hence the need to handle multiple link STA parameters within a composite sta_info object called the MLD STA. The different link STA part of MLD STA are identified using the link address which can be same or different as the MLD STA address and unique link id based on the link vif. To support extension of such a model, the sta_info datastructure is modified to hold multiple link STA objects with link specific params currently within sta_info moved to this new structure. Similarly this is done for ieee80211_sta as well which will be accessed within mac80211 as well as by drivers, hence trivial driver changes are expected to support this. For current non MLO supported drivers, only one link STA is present and link information is accessed via 'deflink' member. For MLO drivers, we still need to define the APIs etc. to get the correct link ID and access the correct part of the station info. Currently in mac80211, all link STA info are accessed directly via deflink. These will be updated to access via link pointers indexed by link id with MLO support patches, with link id being 0 for non MLO supported cases. Except for couple of macro related changes, below spatch takes care of updating mac80211 and driver code to access to the link STA info via deflink. @ieee80211_sta@ struct ieee80211_sta *s; struct sta_info *si; identifier var = {supp_rates, ht_cap, vht_cap, he_cap, he_6ghz_capa, eht_cap, rx_nss, bandwidth, txpwr}; @@ ( s-> - var + deflink.var | si->sta. - var + deflink.var ) @sta_info@ struct sta_info *si; identifier var = {gtk, pcpu_rx_stats, rx_stats, rx_stats_avg, status_stats, tx_stats, cur_max_bandwidth}; @@ ( si-> - var + deflink.var ) Signed-off-by: Sriram R <quic_srirrama@quicinc.com> Link: https://lore.kernel.org/r/1649086883-13246-1-git-send-email-quic_srirrama@quicinc.com [remove MLO-drivers notes from commit message, not clear yet; run spatch] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Revert "mac80211: do not use low data rates for data frames with no ack flag"Felix Fietkau2021-09-231-4/+0
| | | | | | | | | | | | | | | | | | This reverts commit d333322361e7 ("mac80211: do not use low data rates for data frames with no ack flag"). Returning false early in rate_control_send_low breaks sending broadcast packets, since rate control will not select a rate for it. Before re-introducing a fixed version of this patch, we should probably also make some changes to rate control to be more conservative in selecting rates for no-ack packets and also prevent using probing rates on them, since we won't get any feedback. Fixes: d333322361e7 ("mac80211: do not use low data rates for data frames with no ack flag") Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210906083559.9109-1-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add rate control support for encap offloadRyder Lee2021-06-231-2/+1
| | | | | | | | The software rate control cannot deal with encap offload, so fix it. Signed-off-by: Ryder Lee <ryder.lee@mediatek.com> Link: https://lore.kernel.org/r/20210617163113.75815-3-nbd@nbd.name Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: refactor rc_no_data_or_no_ack_use_min functionPhilipp Borgers2021-06-231-5/+1
| | | | | | | | | | Use newly introduced helper function ieee80211_is_tx_data to check if frame is a data frame. Takes into account that hardware encapsulation can be enabled for a frame and therefore no ieee80211 header is present. Signed-off-by: Philipp Borgers <borgers@mi.fu-berlin.de> Link: https://lore.kernel.org/r/20210519122019.92359-4-borgers@mi.fu-berlin.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: do not use low data rates for data frames with no ack flagPhilipp Borgers2021-06-231-0/+4
| | | | | | | | | | | Data Frames with no ack flag set should be handled by the rate controler. Make sure we reach the rate controler by returning early from rate_control_send_low if the frame is a data frame with no ack flag. Signed-off-by: Philipp Borgers <borgers@mi.fu-berlin.de> Link: https://lore.kernel.org/r/20210519122019.92359-3-borgers@mi.fu-berlin.de Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix station rate table updates on assocFelix Fietkau2021-02-011-1/+2
| | | | | | | | | | | | If the driver uses .sta_add, station entries are only uploaded after the sta is in assoc state. Fix early station rate table updates by deferring them until the sta has been uploaded. Cc: stable@vger.kernel.org Signed-off-by: Felix Fietkau <nbd@nbd.name> Link: https://lore.kernel.org/r/20210201083324.3134-1-nbd@nbd.name [use rcu_access_pointer() instead since we won't dereference here] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: initialize last_rate for S1G STAsThomas Pedersen2020-10-081-0/+1
| | | | | | | | | | | | | last_rate is initialized to zero by sta_info_alloc(), but this indicates legacy bitrate for the last TX rate (and invalid for the last RX rate). To avoid a warning when decoding the last rate as legacy (before a data frame has been sent), initialize them as S1G MCS. Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com> Link: https://lore.kernel.org/r/20201005164522.18069-2-thomas@adapt-ip.com [rename to ieee80211_s1g_sta_rate_init(), seems more appropriate] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: avoid rate init for S1G bandThomas Pedersen2020-09-281-0/+6
| | | | | | | | | | minstrel_ht is confused by the lack of sband->bitrates, and S1G will likely require a unique RC algorithm, so avoid rate init for now if STA is on the S1G band. Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com> Link: https://lore.kernel.org/r/20200922022818.15855-13-thomas@adapt-ip.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: handle S1G low ratesThomas Pedersen2020-09-281-7/+26
| | | | | | | | | | | | | S1G doesn't have legacy (sband->bitrates) rates, only MCS. For now, just send a frame at MCS 0 if a low rate is requested. Note we also redefine (since we're out of TX flags) TX_RC_VHT_MCS as TX_RC_S1G_MCS to indicate an S1G MCS. This is probably OK as VHT MCS is not valid on S1G band and vice versa. Signed-off-by: Thomas Pedersen <thomas@adapt-ip.com> Link: https://lore.kernel.org/r/20200922022818.15855-12-thomas@adapt-ip.com Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: populate debugfs only after cfg80211 initJohannes Berg2020-04-241-11/+4
| | | | | | | | | | | | | | | | | | | | | | | When fixing the initialization race, we neglected to account for the fact that debugfs is initialized in wiphy_register(), and some debugfs things went missing (or rather were rerooted to the global debugfs root). Fix this by adding debugfs entries only after wiphy_register(). This requires some changes in the rate control code since it currently adds debugfs at alloc time, which can no longer be done after the reordering. Reported-by: Jouni Malinen <j@w1.fi> Reported-by: kernel test robot <rong.a.chen@intel.com> Reported-by: Hauke Mehrtens <hauke@hauke-m.de> Reported-by: Felix Fietkau <nbd@nbd.name> Cc: stable@vger.kernel.org Fixes: 52e04b4ce5d0 ("mac80211: fix race in ieee80211_register_hw()") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Sumit Garg <sumit.garg@linaro.org> Link: https://lore.kernel.org/r/20200423111344.0e00d3346f12.Iadc76a03a55093d94391fc672e996a458702875d@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/netDavid S. Miller2019-06-221-4/+1
|\ | | | | | | | | | | Minor SPDX change conflict. Signed-off-by: David S. Miller <davem@davemloft.net>
| * treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500Thomas Gleixner2019-06-191-4/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: Enrico Weigelt <info@metux.net> Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org> Reviewed-by: Allison Randal <allison@lohutok.net> Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | mac80211: extend __rate_control_send_low warningJohannes Berg2019-06-141-1/+3
| | | | | | | | | | | | | | | | | | This appears to happen occasionally, and if it does we really want even more information than we have now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: fill low rate even for HAS_RATE_CONTROLJohannes Berg2019-06-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If HW advertises it has rate control, we skip all of the rate control assignments, but sometimes the data we have here is useful, especially so that we don't have to do the lookups again on which rates are configured and are supported. So do the low rate assignment anyway to help out drivers that might need it. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: use STA info in rate_control_send_low()Johannes Berg2019-06-141-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Even if we have a station, we currently call rate_control_send_low() with the NULL station unless further rate control (driver, minstrel) has been initialized. Change this so we can use more information about the station to use a better rate. For example, when we associate with an AP, we will now use the lowest rate it advertised as supported (that we can) rather than the lowest mandatory rate. This aligns our behaviour with most other 802.11 implementations. To make this possible, we need to also ensure that we have non-zero rates at all times, so in case we really have *nothing* pre-fill the supp_rates bitmap with the very lowest mandatory bitmap (11b and 11a on 2.4 and 5 GHz respectively). Additionally, hostapd appears to be giving us an empty supported rates bitmap (it can and should do better, since the STA must have supported for at least the basic rates in the BSS), so ignore any such bitmaps that would actually zero out the supp_rates, and in that case just keep the pre-filled mandatory rates. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Luca Coelho <luciano.coelho@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: call rate_control_send_low() internallyJohannes Berg2019-06-141-6/+7
|/ | | | | | | | There's no rate control algorithm that *doesn't* want to call it internally, and calling it internally will let us modify its behaviour in the future. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Dynamically set CoDel parameters per stationToke Høiland-Jørgensen2017-05-171-1/+2
| | | | | | | | | | | | | | | | | | | | | | CoDel can be too aggressive if a station sends at a very low rate, leading reduced throughput. This gets worse the more stations are present, as each station gets more bursty the longer the round-robin scheduling between stations takes. This adds dynamic adjustment of CoDel parameters per station. It uses the rate selection information to estimate throughput and sets more lenient CoDel parameters if the estimated throughput is below a threshold (modified by the number of active stations). A new callback is added that drivers can use to notify mac80211 about changes in expected throughput, so the same adjustment can be made for cards that implement rate control in firmware. Drivers that don't use this will just get the default parameters. Signed-off-by: Toke Høiland-Jørgensen <toke@toke.dk> [remove currently unnecessary EXPORT_SYMBOL, fix kernel-doc, remove inline annotation] Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Fix possible sband related NULL pointer de-referenceMohammed Shafi Shajakhan2017-04-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even if the channel context configuration is NULL. This crashes for chipsets which support 5 Ghz alone when it tries to access members of 'sband'. Channel context configuration can be NULL in multivif case and when channel switch is in progress (or) when it fails. Fix this by replacing the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which returns a NULL pointer for sband when the channel configuration is NULL. An example scenario is as below: In multivif mode (AP + STA) with drivers like ath10k, when we do a channel switch in the AP vif (which has a number of clients connected) and a STA vif which is connected to some other AP, when the channel switch in AP vif fails, while the STA vifs tries to connect to the other AP, there is a window where the channel context is NULL/invalid and this results in a crash while the clients connected to the AP vif tries to reconnect and this race is very similar to the one investigated by Michal in https://patchwork.kernel.org/patch/3788161/ and this does happens with hardware that supports 5Ghz alone after long hours of testing with continuous channel switch on the AP vif ieee80211 phy0: channel context reservation cannot be finalized because some interfaces aren't switching wlan0: failed to finalize CSA, disconnecting wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice (Reason: 3=DEAUTH_LEAVING) WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211] [<bf77272c>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211])) [<bf73cc50>] (nl80211_new_station [cfg80211]) Unable to handle kernel NULL pointer dereference at virtual address 00000014 pgd = d5f4c000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM PC is at sta_info_alloc+0x380/0x3fc [mac80211] LR is at sta_info_alloc+0x37c/0x3fc [mac80211] [<bf772738>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211]) [<bf73cc50>] (nl80211_new_station [cfg80211])) Cc: Michal Kazior <michal.kazior@tieto.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed@qti.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: make rate control tx status API more extensibleFelix Fietkau2017-04-281-0/+22
| | | | | | | | | | | Rename .tx_status_noskb to .tx_status_ext and pass a new on-stack struct ieee80211_tx_status instead of struct ieee80211_tx_info. This struct can be used to pass extra information, e.g. for dynamic tx power control Signed-off-by: Felix Fietkau <nbd@nbd.name> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: Fix clang warning about constant operand in logical operationMatthias Kaehlcke2017-04-131-2/+4
| | | | | | | | | | | | | | | When clang detects a non-boolean constant in a logical operation it generates a 'constant-logical-operand' warning. In ieee80211_try_rate_control_ops_get() the result of strlen(<const str>) is used in a logical operation, clang resolves the expression to an (integer) constant at compile time when clang's builtin strlen function is used. Change the condition to check for strlen() > 0 to make the constant operand boolean and thus avoid the warning. Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: reject/clear user rate mask if not usableJohannes Berg2017-03-081-0/+27
| | | | | | | | | | | | | | | | | | | | If the user rate mask results in no (basic) rates being usable, clear it. Also, if we're already operating when it's set, reject it instead. Technically, selecting basic rates as the criterion is a bit too restrictive, but calculating the usable rates over all stations (e.g. in AP mode) is harder, and all stations must support the basic rates. Similarly, in client mode, the basic rates will be used anyway for control frames. This fixes the "no supported rates (...) in rate_mask ..." warning that occurs on TX when you've selected a rate mask that's not compatible with the connection (e.g. an AP that enables only the rates 36, 48, 54 and you've selected only 6, 9, 12.) Reported-by: Kirtika Ruchandani <kirtika@google.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove local pointer from rate_ctrl_refJohannes Berg2017-03-061-5/+5
| | | | | | This pointer really isn't needed, so remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: don't try to sleep in rate_control_rate_init()Johannes Berg2017-01-241-2/+0
| | | | | | | | | | | | In my previous patch, I missed that rate_control_rate_init() is called from some places that cannot sleep, so it cannot call ieee80211_recalc_min_chandef(). Remove that call for now to fix the context bug, we'll have to find a different way to fix the minimum channel width issue. Fixes: 96aa2e7cf126 ("mac80211: calculate min channel width correctly") Reported-by: Xiaolong Ye (via lkp-robot) <xiaolong.ye@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: calculate min channel width correctlyJohannes Berg2017-01-111-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | In the current minimum chandef code there's an issue in that the recalculation can happen after rate control is initialized for a station that has a wider bandwidth than the current chanctx, and then rate control can immediately start using those higher rates which could cause problems. Observe that first of all that this problem is because we don't take non-associated and non-uploaded stations into account. The restriction to non-associated is quite pointless and is one of the causes for the problem described above, since the rate init will happen before the station is set to associated; no frames could actually be sent until associated, but the rate table can already contain higher rates and that might cause problems. Also, rejecting non-uploaded stations is wrong, since the rate control can select higher rates for those as well. Secondly, it's then necessary to recalculate the minimal config before initializing rate control, so that when rate control is initialized, the higher rates are already available. This can be done easily by adding the necessary function call in rate init. Change-Id: Ib9bc02d34797078db55459d196993f39dcd43070 Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* cfg80211: remove enum ieee80211_bandJohannes Berg2016-04-121-1/+1
| | | | | | | | | This enum is already perfectly aliased to enum nl80211_band, and the only reason for it is that we get IEEE80211_NUM_BANDS out of it. There's no really good reason to not declare the number of bands in nl80211 though, so do that and remove the cfg80211 one. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: further improve "no supported rates" warningJohannes Berg2015-11-031-1/+1
| | | | | | | | | | | Allow distinguishing the non-station case from the case of a station without rates, by using -1 for the non-station case. This value cannot be reached with a station since that many legacy rates don't exist. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge tag 'mac80211-next-for-davem-2015-10-05' of ↵David S. Miller2015-10-071-1/+4
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next Johannes Berg says: ==================== For the current cycle, we have the following right now: * many internal fixes, API improvements, cleanups, etc. * full AP client state tracking in cfg80211/mac80211 from Ayala * VHT support (in mac80211) for mesh * some A-MSDU in A-MPDU support from Emmanuel * show current TX power to userspace (from Rafał) * support for netlink dump in vendor commands (myself) ==================== Signed-off-by: David S. Miller <davem@davemloft.net>
| * mac80211: improve __rate_control_send_low warningJohannes Berg2015-09-291-1/+4
| | | | | | | | | | | | | | | | | | If there are no supported rates in the rate mask with the required flags, we warn, but it's not clear which part causes the warning. Add the relevant data to the warning to understand why it happens. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: Do not use sizeof() on pointer typeThierry Reding2015-09-041-1/+1
|/ | | | | | | | | | | | | | | | | | | | The rate_control_cap_mask() function takes a parameter mcs_mask, which GCC will take to be u8 * even though it was declared with a fixed size. This causes the following warning: net/mac80211/rate.c: In function 'rate_control_cap_mask': net/mac80211/rate.c:719:25: warning: 'sizeof' on array function parameter 'mcs_mask' will return size of 'u8 * {aka unsigned char *}' [-Wsizeof-array-argument] for (i = 0; i < sizeof(mcs_mask); i++) ^ net/mac80211/rate.c:684:10: note: declared here u8 mcs_mask[IEEE80211_HT_MCS_MASK_LEN], ^ This can be easily fixed by using the IEEE80211_HT_MCS_MASK_LEN directly within the loop condition. Signed-off-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add rate mask logic for vht ratesLorenzo Bianconi2015-08-141-11/+91
| | | | | | | | Define rc_rateidx_vht_mcs_mask array and rate_idx_match_vht_mcs_mask() method in order to apply mcs mask for vht rates Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: define rate_control_apply_mask_ratetbl()Lorenzo Bianconi2015-08-141-0/+27
| | | | | | | | Define rate_control_apply_mask_ratetbl() in order to apply ratemask in rate_control_set_rates() for station rate table Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove ieee80211_tx_rate dependency in rate mask codeLorenzo Bianconi2015-08-141-68/+71
| | | | | | | | | | | Remove ieee80211_tx_rate dependency in rate_idx_match_legacy_mask(), rate_idx_match_mcs_mask() and rate_idx_match_mask() in order to use the previous logic to define a ratemask in rate_control_set_rates() for station rate table. Moreover move rate mask definition logic in rate_control_cap_mask() Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove ieee80211_tx_info from rate_control_apply_mask signatureLorenzo Bianconi2015-08-141-6/+5
| | | | | | | | | Remove unnecessary ieee80211_tx_info pointer from rate_control_apply_mask signature. rate_control_apply_mask() will be used to define a ratemask in rate_control_set_rates() for station rate table Signed-off-by: Lorenzo Bianconi <lorenzo.bianconi83@gmail.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: deinline rate_control_rate_init, rate_control_rate_updateDenys Vlasenko2015-07-171-0/+59
| | | | | | | | | | | | | | | | | | | | With this .config: http://busybox.net/~vda/kernel_config, after deinlining these functions have sizes and callsite counts as follows: rate_control_rate_init: 554 bytes, 8 calls rate_control_rate_update: 1596 bytes, 5 calls Total size reduction: about 11 kbytes. Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com> CC: John Linville <linville@tuxdriver.com> CC: Michal Kazior <michal.kazior@tieto.com> CC: Johannes Berg <johannes.berg@intel.com> Cc: linux-wireless@vger.kernel.org Cc: netdev@vger.kernel.org CC: linux-kernel@vger.kernel.org Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* Merge tag 'modules-next-for-linus' of ↵Linus Torvalds2015-07-011-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux Pull module updates from Rusty Russell: "Main excitement here is Peter Zijlstra's lockless rbtree optimization to speed module address lookup. He found some abusers of the module lock doing that too. A little bit of parameter work here too; including Dan Streetman's breaking up the big param mutex so writing a parameter can load another module (yeah, really). Unfortunately that broke the usual suspects, !CONFIG_MODULES and !CONFIG_SYSFS, so those fixes were appended too" * tag 'modules-next-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux: (26 commits) modules: only use mod->param_lock if CONFIG_MODULES param: fix module param locks when !CONFIG_SYSFS. rcu: merge fix for Convert ACCESS_ONCE() to READ_ONCE() and WRITE_ONCE() module: add per-module param_lock module: make perm const params: suppress unused variable error, warn once just in case code changes. modules: clarify CONFIG_MODULE_COMPRESS help, suggest 'N'. kernel/module.c: avoid ifdefs for sig_enforce declaration kernel/workqueue.c: remove ifdefs over wq_power_efficient kernel/params.c: export param_ops_bool_enable_only kernel/params.c: generalize bool_enable_only kernel/module.c: use generic module param operaters for sig_enforce kernel/params: constify struct kernel_param_ops uses sysfs: tightened sysfs permission checks module: Rework module_addr_{min,max} module: Use __module_address() for module_address_lookup() module: Make the mod_tree stuff conditional on PERF_EVENTS || TRACING module: Optimize __module_address() using a latched RB-tree rbtree: Implement generic latch_tree seqlock: Introduce raw_read_seqcount_latch() ...
| * module: add per-module param_lockDan Streetman2015-06-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add a "param_lock" mutex to each module, and update params.c to use the correct built-in or module mutex while locking kernel params. Remove the kparam_block_sysfs_r/w() macros, replace them with direct calls to kernel_param_[un]lock(module). The kernel param code currently uses a single mutex to protect modification of any and all kernel params. While this generally works, there is one specific problem with it; a module callback function cannot safely load another module, i.e. with request_module() or even with indirect calls such as crypto_has_alg(). If the module to be loaded has any of its params configured (e.g. with a /etc/modprobe.d/* config file), then the attempt will result in a deadlock between the first module param callback waiting for modprobe, and modprobe trying to lock the single kernel param mutex to set the new module's param. This fixes that by using per-module mutexes, so that each individual module is protected against concurrent changes in its own kernel params, but is not blocked by changes to other module params. All built-in modules continue to use the built-in mutex, since they will always be loaded at runtime and references (e.g. request_module(), crypto_has_alg()) to them will never cause load-time param changing. This also simplifies the interface used by modules to block sysfs access to their params; while there are currently functions to block and unblock sysfs param access which are split up by read and write and expect a single kernel param to be passed, their actual operation is identical and applies to all params, not just the one passed to them; they simply lock and unlock the global param mutex. They are replaced with direct calls to kernel_param_[un]lock(THIS_MODULE), which locks THIS_MODULE's param_lock, or if the module is built-in, it locks the built-in mutex. Suggested-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Dan Streetman <ddstreet@ieee.org> Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
* | mac80211: convert HW flags to unsigned long bitmapJohannes Berg2015-06-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As we're running out of hardware capability flags pretty quickly, convert them to use the regular test_bit() style unsigned long bitmaps. This introduces a number of helper functions/macros to set and to test the bits, along with new debugfs code. The occurrences of an explicit __clear_bit() are intentional, the drivers were never supposed to change their supported bits on the fly. We should investigate changing this to be a per-frame flag. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* | mac80211: lock rate controlJohannes Berg2015-04-201-1/+7
|/ | | | | | | | | | | | | | | | | | | | | | | | Both minstrel (reported by Sven Eckelmann) and the iwlwifi rate control aren't properly taking concurrency into account. It's likely that the same is true for other rate control algorithms. In the case of minstrel this manifests itself in crashes when an update and other data access are run concurrently, for example when the stations change bandwidth or similar. In iwlwifi, this can cause firmware crashes. Since fixing all rate control algorithms will be very difficult, just provide locking for invocations. This protects the internal data structures the algorithms maintain. I've manipulated hostapd to test this, by having it change its advertised bandwidth roughly ever 150ms. At the same time, I'm running a flood ping between the client and the AP, which causes this race of update vs. get_rate/status to easily happen on the client. With this change, the system survives this test. Reported-by: Sven Eckelmann <sven@open-mesh.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: add more missing checks for VHT tx ratesFelix Fietkau2014-11-281-1/+2
| | | | | | | | | Fixes a crash on attempting to calculate the frame duration for a VHT packet (which needs to be handled by hw/driver instead). Reported-by: Jouni Malinen <j@w1.fi> Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: notify drivers on sta rate table changesJohannes Berg2014-11-191-0/+3
| | | | | | | | | This allows drivers with a firmware or chip-based rate lookup table to use the most recent default rate selection without having to get it from per-packet data or explicit ieee80211_get_tx_rate calls Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: skip legacy rate mask handling for VHT ratesFelix Fietkau2014-11-191-1/+1
| | | | | | | | | The rate mask code currently assumes that a rate is legacy if IEEE80211_TX_RC_MCS is not set. This might be the cause of bogus VHT rates being reported with minstrel_ht. Signed-off-by: Felix Fietkau <nbd@openwrt.org> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix typo in starting baserate for rts_cts_rate_idxKarl Beldan2014-10-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | It affects non-(V)HT rates and can lead to selecting an rts_cts rate that is not a basic rate or way superior to the reference rate (ATM rates[0] used for the 1st attempt of the protected frame data). E.g, assuming drivers register growing (bitrate) sorted tables of ieee80211_rate-s, having : - rates[0].idx == d'2 and basic_rates == b'10100 will select rts_cts idx b'10011 & ~d'(BIT(2)-1), i.e. 1, likewise - rates[0].idx == d'2 and basic_rates == b'10001 will select rts_cts idx b'10000 The first is not a basic rate and the second is > rates[0]. Also, wrt severity of the addressed misbehavior, ATM we only have one rts_cts_rate_idx rather than one per rate table entry, so this idx might still point to bitrates > rates[1..MAX_RATES]. Fixes: 5253ffb8c9e1 ("mac80211: always pick a basic rate to tx RTS/CTS for pre-HT rates") Cc: stable@vger.kernel.org Signed-off-by: Karl Beldan <karl.beldan@rivierawaves.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: remove module handling from rate control opsJohannes Berg2014-02-041-23/+9
| | | | | | | | | | | | There's not a single rate control algorithm actually in a separate module where the module refcount would be required. Similarly, there's no specific rate control module. Therefore, all the module handling code in rate control is really just dead code, so remove it. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: make rate control ops constJohannes Berg2014-02-041-8/+8
| | | | | | | | Change the code to allow making all the rate control ops const, nothing ever needs to change them. Also change all drivers to make use of this and mark the ops const. Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: respect rate mask in TXAndrei Otcheretianski2013-10-151-3/+9
| | | | | | | | | | Bitrate mask were not respected in transmissions, causing (for example) P2P GO/client to use CCK rates for auth and assoc frames. Fix it by considering the rate mask in __rate_control_send_low(). Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: fix honouring rate flags in low-rate transmitAndrei Otcheretianski2013-10-151-0/+3
| | | | | | | | | | | | | | Transmissions with the IEEE80211_TX_CTL_NO_CCK_RATE flag set (which can come from userspace) were no longer guaranteed to be transmitted with allowed rates since commit 2103dec14792b ("mac80211: select and adjust bitrates according to channel mode") due to a missing rate_flags check in that commit. The commit also introduced the need to check the 5/10 MHz flags but accidentally didn't. Fix it by adding the missing check. Signed-off-by: Andrei Otcheretianski <andrei.otcheretianski@intel.com> Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: allow lowest basic rate for unicast management for meshChun-Yeow Yeoh2013-08-091-7/+16
| | | | | | | | | | | Allow lowest basic rate to be used for unicast management frame in mesh. Otherwise, the lowest supported rate is used for unicast management frame, such as 1Mbps for 2.4GHz and 6Mbps for 5GHz. Rename the rc_send_low_broadcast to re_send_low_basicrate since now it is also applied to unicast management frame in mesh. Signed-off-by: Chun-Yeow Yeoh <yeohchunyeow@cozybit.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
* mac80211: select and adjust bitrates according to channel modeSimon Wunderlich2013-07-161-24/+22
| | | | | | | | | | | | | | | | The various components accessing the bitrates table must use consider the used channel bandwidth to select only available rates or calculate the bitrate correctly. There are some rates in reduced bandwidth modes which can't be represented as multiples of 500kbps, like 2.25 MBit/s in 5 MHz mode. The standard suggests to round up to the next multiple of 500kbps, just do that in mac80211 as well. Signed-off-by: Simon Wunderlich <siwu@hrz.tu-chemnitz.de> Signed-off-by: Mathias Kretschmer <mathias.kretschmer@fokus.fraunhofer.de> [make rate unsigned in ieee80211_add_tx_radiotap_header(), squash fix] Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
* Merge remote-tracking branch 'mac80211/master' into HEADJohannes Berg2013-06-191-1/+1
|\ | | | | | | | | | | | | | | | | | | | | Merge mac80211 to avoid conflicts with the nl80211 attrbuf changes. Conflicts: net/mac80211/iface.c net/wireless/nl80211.c Signed-off-by: Johannes Berg <johannes.berg@intel.com>
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-25 22:34:51 +0100