1. 19 Jun, 2019 1 commit
  2. 14 Jun, 2019 4 commits
  3. 17 May, 2017 1 commit
    • Toke Høiland-Jørgensen's avatar
      mac80211: Dynamically set CoDel parameters per station · 484a54c2
      Toke Høiland-Jørgensen authored
      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: default avatarToke Høiland-Jørgensen <toke@toke.dk>
      [remove currently unnecessary EXPORT_SYMBOL, fix kernel-doc, remove
      inline annotation]
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  4. 28 Apr, 2017 2 commits
    • Mohammed Shafi Shajakhan's avatar
      mac80211: Fix possible sband related NULL pointer de-reference · 21a8e9dd
      Mohammed Shafi Shajakhan authored
      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: default avatarMohammed Shafi Shajakhan <mohammed@qti.qualcomm.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
    • Felix Fietkau's avatar
      mac80211: make rate control tx status API more extensible · 18fb84d9
      Felix Fietkau authored
      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: default avatarFelix Fietkau <nbd@nbd.name>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  5. 13 Apr, 2017 1 commit
  6. 08 Mar, 2017 1 commit
    • Johannes Berg's avatar
      mac80211: reject/clear user rate mask if not usable · e8e4f528
      Johannes Berg authored
      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: default avatarKirtika Ruchandani <kirtika@google.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  7. 06 Mar, 2017 1 commit
  8. 24 Jan, 2017 1 commit
  9. 11 Jan, 2017 1 commit
    • Johannes Berg's avatar
      mac80211: calculate min channel width correctly · 96aa2e7c
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
  10. 12 Apr, 2016 1 commit
  11. 03 Nov, 2015 1 commit
  12. 29 Sep, 2015 1 commit
  13. 04 Sep, 2015 1 commit
    • Thierry Reding's avatar
      mac80211: Do not use sizeof() on pointer type · 98a1f828
      Thierry Reding authored
      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: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  14. 14 Aug, 2015 4 commits
  15. 17 Jul, 2015 1 commit
  16. 23 Jun, 2015 1 commit
    • Dan Streetman's avatar
      module: add per-module param_lock · b51d23e4
      Dan Streetman authored
      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: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarDan Streetman <ddstreet@ieee.org>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
  17. 10 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: convert HW flags to unsigned long bitmap · 30686bf7
      Johannes Berg authored
      As we're running out of hardware capability flags pretty quickly,
      convert them to use the regular test_bit() style unsigned long
      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: default avatarJohannes Berg <johannes.berg@intel.com>
  18. 20 Apr, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: lock rate control · 35c347ac
      Johannes Berg authored
      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: default avatarSven Eckelmann <sven@open-mesh.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  19. 28 Nov, 2014 1 commit
  20. 19 Nov, 2014 2 commits
  21. 14 Oct, 2014 1 commit
    • Karl Beldan's avatar
      mac80211: fix typo in starting baserate for rts_cts_rate_idx · c7abf25a
      Karl Beldan authored
      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: 5253ffb8 ("mac80211: always pick a basic rate to tx RTS/CTS for pre-HT rates")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarKarl Beldan <karl.beldan@rivierawaves.com>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  22. 04 Feb, 2014 2 commits
  23. 15 Oct, 2013 2 commits
  24. 09 Aug, 2013 1 commit
  25. 16 Jul, 2013 1 commit
  26. 18 Jun, 2013 1 commit
  27. 12 Jun, 2013 1 commit
  28. 16 May, 2013 1 commit
  29. 22 Apr, 2013 1 commit
    • Felix Fietkau's avatar
      mac80211: improve the rate control API · 0d528d85
      Felix Fietkau authored
      Allow rate control modules to pass a rate selection table to mac80211
      and the driver. This allows drivers to fetch the most recent rate
      selection from the sta pointer for already buffered frames. This allows
      rate control to respond faster to sudden link changes and it is also a
      step towards adding minstrel_ht support to drivers like iwlwifi.
      When a driver sets IEEE80211_HW_SUPPORTS_RC_TABLE, mac80211 will not
      fill info->control.rates with rates from the rate table (to preserve
      explicit overrides by the rate control module). The driver then
      explicitly calls ieee80211_get_tx_rates to merge overrides from
      info->control.rates with defaults from the sta rate table.
      Signed-off-by: default avatarFelix Fietkau <nbd@openwrt.org>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
  30. 16 Apr, 2013 1 commit