1. 26 7月, 2018 7 次提交
  2. 25 7月, 2018 30 次提交
  3. 24 7月, 2018 3 次提交
    • M
      mac80211: restrict delayed tailroom needed decrement · 133bf90d
      Manikanta Pubbisetty 提交于
      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 for other iftypes may be unnecessary.
      
      For example, let's consider the case of a 4-addr client connecting to
      an AP for which AP_VLAN interface is also created, let the initial
      value for tailroom_needed on the AP be 1.
      
      * 4-addr client connects to the AP (AP: tailroom_needed = 1)
      * AP will clear old keys, delay decrement of tailroom_needed count
      * AP_VLAN is created, it takes the tailroom count from master
        (AP_VLAN: tailroom_needed = 1, AP: tailroom_needed = 1)
      * Install new key for the station, assume key is plumbed in the HW,
        there won't be any change in tailroom_needed count on AP iface
      * Delayed decrement of tailroom_needed count on AP
        (AP: tailroom_needed = 0, AP_VLAN: tailroom_needed = 1)
      
      Because of the delayed decrement on AP iface, tailroom_needed count goes
      out of sync between AP(master iface) and AP_VLAN(slave iface) and
      there would be unnecessary tailroom created for the packets going
      through AP_VLAN iface.
      
      Also, WARN_ONs were observed while trying to bring down the AP_VLAN
      interface:
      (warn_slowpath_common) (warn_slowpath_null+0x18/0x20)
      (warn_slowpath_null) (ieee80211_free_keys+0x114/0x1e4)
      (ieee80211_free_keys) (ieee80211_del_virtual_monitor+0x51c/0x850)
      (ieee80211_del_virtual_monitor) (ieee80211_stop+0x30/0x3c)
      (ieee80211_stop) (__dev_close_many+0x94/0xb8)
      (__dev_close_many) (dev_close_many+0x5c/0xc8)
      
      Restricting delayed decrement to station interface alone fixes the problem
      and it makes sense to do so because delayed decrement is done to improve
      roam time which is applicable only for client devices.
      Signed-off-by: NManikanta Pubbisetty <mpubbise@codeaurora.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      133bf90d
    • K
      wireless/lib80211: Convert from ahash to shash · d17504b1
      Kees Cook 提交于
      In preparing to remove all stack VLA usage from the kernel[1], this
      removes the discouraged use of AHASH_REQUEST_ON_STACK in favor of
      the smaller SHASH_DESC_ON_STACK by converting from ahash-wrapped-shash
      to direct shash. The stack allocation will be made a fixed size in a
      later patch to the crypto subsystem.
      
      [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.comSigned-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
      d17504b1
    • D
      Merge tag 'wireless-drivers-next-for-davem-2018-07-23' of... · a527d3f7
      David S. Miller 提交于
      Merge tag 'wireless-drivers-next-for-davem-2018-07-23' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers-next
      
      Kalle Valo says:
      
      ====================
      wireless-drivers-next patches for 4.19
      
      The first set of patches for 4.19. Only smaller features and bug
      fixes, not really anything major. Also included are changes to
      include/linux/bitfield.h, we agreed with Johannes that it makes sense
      to apply them via wireless-drivers-next.
      
      Major changes:
      
      ath10k
      
      * support channel 173
      
      * fix spectral scan for QCA9984 and QCA9888 chipsets
      
      ath6kl
      
      * add support for Dell Wireless 1537
      
      ti wlcore
      
      * add support for runtime PM
      
      * enable runtime PM autosuspend support
      
      qtnfmac
      
      * support changing MAC address
      
      * enable source MAC address randomization support
      
      libertas
      
      * fix suspend and resume for SDIO cards
      
      mt76
      
      * add software DFS radar pattern detector for mt76x2 based devices
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      a527d3f7