Skip to content

GitLab

Switch branch/tag
  1. 19 Oct, 2018 1 commit
    • Manikanta Pubbisetty's avatar
      mac80211: restrict delayed tailroom needed decrement · cbb4669a
      Manikanta Pubbisetty authored 
      BugLink: https://bugs.launchpad.net/bugs/1798587

[ Upstream commit 133bf90d ]

As explained in ieee80211_delayed_tailroom_dec(), during roam,
keys of the old AP will be destroyed and new keys will be
installed. Deletion of the old key causes
crypto_tx_tailroom_needed_cnt to go from 1 to 0 and the new key
installation causes a transition from 0 to 1.

Whenever crypto_tx_tailroom_needed_cnt transitions from 0 to 1,
we invoke synchronize_net(); the reason for doing this is to avoid
a race in the TX path as explained in increment_tailroom_need_count().
This synchronize_net() operation can be slow and can affect the station
roam time. To avoid this, decrementing the crypto_tx_tailroom_needed_cnt
is delayed for a while so that upon installation of new key the
transition would be from 1 to 2 instead of 0 to 1 and thereby
improving the roam time.

This is all correct for a STA iftype, but deferring the tailroom_needed
decrement ...
      cbb4669a
  3. 13 Mar, 2018 3 commits
  5. 17 Jul, 2015 1 commit
  7. 21 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: fix locking in update_vlan_tailroom_need_count() · 51f458d9
      Johannes Berg authored 
      Unfortunately, Michal's change to fix AP_VLAN crypto tailroom
caused a locking issue that was reported by lockdep, but only
in a few cases - the issue was a classic ABBA deadlock caused
by taking the mtx after the key_mtx, where normally they're
taken the other way around.

As the key mutex protects the field in question (I'm adding a
few annotations to make that clear) only the iteration needs
to be protected, but we can also iterate the interface list
with just RCU protection while holding the key mutex.

Fixes: f9dca80b

 ("mac80211: fix AP_VLAN crypto tailroom calculation")
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      51f458d9
  9. 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
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: default avatarJohannes Berg <johannes.berg@intel.com>
      30686bf7
  11. 02 Jun, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: move TX PN to public part of key struct · db388a56
      Johannes Berg authored 
      
For drivers supporting TSO or similar features, but that still have
PN assignment in software, there's a need to have some memory to
store the current PN value. As mac80211 already stores this and it's
somewhat complicated to add a per-driver area to the key struct (due
to the dynamic sizing thereof) it makes sense to just move the TX PN
to the keyconf, i.e. the public part of the key struct.

As TKIP is more complicated and we won't able to offload it in this
way right now (fast-xmit is skipped for TKIP unless the HW does it
all, and our hardware needs MMIC calculation in software) I've not
moved that for now - it's possible but requires exposing a lot of
the internal TKIP state.

As an bonus side effect, we can remove a lot of code by assuming the
keyseq struct has a certain layout - with BUILD_BUG_ON to verify it.

This might also improve performance, since now TX and RX no longer
share a cacheline.
Reviewed-by: default avatarEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      db388a56
  13. 20 May, 2015 1 commit
    • Michal Kazior's avatar
      mac80211: fix AP_VLAN crypto tailroom calculation · f9dca80b
      Michal Kazior authored 
      
Some splats I was seeing:

 (a) WARNING: CPU: 1 PID: 0 at /devel/src/linux/net/mac80211/wep.c:102 ieee80211_wep_add_iv
 (b) WARNING: CPU: 1 PID: 0 at /devel/src/linux/net/mac80211/wpa.c:73 ieee80211_tx_h_michael_mic_add
 (c) WARNING: CPU: 3 PID: 0 at /devel/src/linux/net/mac80211/wpa.c:433 ieee80211_crypto_ccmp_encrypt

I've seen (a) and (b) with ath9k hw crypto and (c)
with ath9k sw crypto. All of them were related to
insufficient skb tailroom and I was able to
trigger these with ping6 program.

AP_VLANs may inherit crypto keys from parent AP.
This wasn't considered and yielded problems in
some setups resulting in inability to transmit
data because mac80211 wouldn't resize skbs when
necessary and subsequently drop some packets due
to insufficient tailroom.

For efficiency purposes don't inspect both AP_VLAN
and AP sdata looking for tailroom counter. Instead
update AP_VLAN tailroom counters whenever their
master AP tailroom counter changes.
Signed-off-by: default avatarMichal Kazior <michal.kazior@tieto.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      f9dca80b
  15. 06 May, 2015 2 commits
  17. 22 Apr, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: add TX fastpath · 17c18bf8
      Johannes Berg authored 
      
In order to speed up mac80211's TX path, add the "fast-xmit" cache
that will cache the data frame 802.11 header and other data to be
able to build the frame more quickly. This cache is rebuilt when
external triggers imply changes, but a lot of the checks done per
packet today are simplified away to the check for the cache.

There's also a more detailed description in the code.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      17c18bf8
  19. 17 Mar, 2015 1 commit
  21. 27 Jan, 2015 4 commits
  23. 22 Jan, 2015 1 commit
    • Johannes Berg's avatar
      mac80211: allow drivers to control software crypto · fa7e1fbc
      Johannes Berg authored 
      
Some drivers unfortunately cannot support software crypto, but
mac80211 currently assumes that they do.

This has the issue that if the hardware enabling fails for some
reason, the software fallback is used, which won't work. This
clearly isn't desirable, the error should be reported and the
key setting refused.

Support this in mac80211 by allowing drivers to set a new HW
flag IEEE80211_HW_SW_CRYPTO_CONTROL, in which case mac80211 will
only allow software fallback if the set_key() method returns 1.
The driver will also need to advertise supported cipher suites
so that mac80211 doesn't advertise any (future) software ciphers
that the driver can't actually do.

While at it, to make it easier to support this, refactor the
ieee80211_init_cipher_suites() code.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      fa7e1fbc
  25. 07 Jan, 2015 1 commit
    • Ido Yariv's avatar
      mac80211: Re-fix accounting of the tailroom-needed counter · db12847c
      Ido Yariv authored 
      When hw acceleration is enabled, the GENERATE_IV or PUT_IV_SPACE flags
only require headroom space. Therefore, the tailroom-needed counter can
safely be decremented for most drivers.

The older incarnation of this patch (ca34e3b5

) assumed that the above
holds true for all drivers. As reported by Christopher Chavez and
researched by Christian Lamparter and Larry Finger, this isn't a valid
assumption for p54 and cw1200.

Drivers that still require tailroom for ICV/MIC even when HW encryption
is enabled can use IEEE80211_KEY_FLAG_RESERVE_TAILROOM to indicate it.
Signed-off-by: default avatarIdo Yariv <idox.yariv@intel.com>
Cc: Christopher Chavez <chrischavez@gmx.us>
Cc: Christian Lamparter <chunkeey@googlemail.com>
Cc: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Solomon Peachy <pizza@shaftnet.org>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      db12847c
  27. 05 Jan, 2015 1 commit
  29. 17 Dec, 2014 1 commit
  31. 22 Oct, 2014 1 commit
  33. 11 Sep, 2014 1 commit
  35. 05 Sep, 2014 1 commit
  37. 26 Aug, 2014 1 commit
  39. 21 Jul, 2014 1 commit
  41. 29 Apr, 2014 1 commit
    • Johannes Berg's avatar
      mac80211: remove BUG_ON usage · 8c5bb1fa
      Johannes Berg authored 
      
These BUG_ON statements should never trigger, but in the unlikely
event that somebody does manage don't stop everything but simply
exit the code path with an error.

Leave the one BUG_ON where changing it would result in a NULL
pointer dereference.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8c5bb1fa
  43. 16 Dec, 2013 2 commits
  45. 25 Nov, 2013 2 commits
  47. 26 Sep, 2013 1 commit
  49. 16 Aug, 2013 1 commit
    • Johannes Berg's avatar
      mac80211: add APIs to allow keeping connections after WoWLAN · 27b3eb9c
      Johannes Berg authored 
      
In order to be able to (securely) keep connections alive after
the system was suspended for WoWLAN, we need some additional
APIs. We already have API (ieee80211_gtk_rekey_notify) to tell
wpa_supplicant about the new replay counter if GTK rekeying
was done by the device while the host was asleep, but that's
not sufficient.

If GTK rekeying wasn't done, we need to tell the host about
sequence counters for the GTK (and PTK regardless of rekeying)
that was used while asleep, add ieee80211_set_key_rx_seq() for
that.

If GTK rekeying was done, then we need to be able to disable
the old keys (with ieee80211_remove_key()) and allocate the
new GTK key(s) in mac80211 (with ieee80211_gtk_rekey_add()).

If protocol offload (e.g. ARP) is implemented, then also the
TX sequence counter for the PTK must be updated, using the new
ieee80211_set_key_tx_seq() function.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      27b3eb9c
  51. 16 May, 2013 1 commit
  53. 11 Mar, 2013 3 commits
  55. 06 Mar, 2013 3 commits
    • Johannes Berg's avatar
      mac80211: defer tailroom counter manipulation when roaming · 8d1f7ecd
      Johannes Berg authored 
      
During roaming, the crypto_tx_tailroom_needed_cnt counter
will often take values 2,1,0,1,2 because first keys are
removed and then new keys are added. This is inefficient
because during the 0->1 transition, synchronize_net must
be called to avoid packet races, although typically no
packets would be flowing during that time.

To avoid that, defer the decrement (2->1, 1->0) when keys
are removed (by half a second). This means the counter
will really have the values 2,2,2,3,4 ... 2, thus never
reaching 0 and having to do the 0->1 transition.

Note that this patch entirely disregards the drivers for
which this optimisation was done to start with, for them
the key removal itself will be expensive because it has
to synchronize_net() after the counter is incremented to
remove the key from HW crypto. For them the sequence will
look like this: 0,1,0,1,0,1,0,1,0 (*) which is clearly a
lot more inefficient. This could be addressed separately,
during key removal the 0->1->0 sequence isn't necessary.

(*) it starts at 0 because HW crypto is on, then goes to
    1 when HW crypto is disabled for a key, then back to
    0 because the key is deleted; this happens for both
    keys in the example. When new keys are added, it goes
    to 1 first because they're added in software; when a
    key is moved to hardware it goes back to 0
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      8d1f7ecd
    • Johannes Berg's avatar
      mac80211: remove IEEE80211_KEY_FLAG_WMM_STA · a8712105
      Johannes Berg authored 
      
There's no driver using this flag, so it seems
that all drivers support HW crypto with WMM or
don't support it at all. Remove the flag and
code setting it.
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      a8712105
    • Stanislaw Gruszka's avatar
      mac80211: cleanup generic suspend/resume procedures · 12e7f517
      Stanislaw Gruszka authored 
      
Since now we disconnect before suspend, various code which save
connection state can now be removed from suspend and resume
procedure. Cleanup on resume side is smaller as ieee80211_reconfig()
is also used for H/W restart.
Signed-off-by: default avatarStanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      12e7f517
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7