1. 27 7月, 2018 1 次提交
  2. 26 7月, 2018 1 次提交
  3. 25 7月, 2018 31 次提交
  4. 24 7月, 2018 7 次提交
    • 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
    • D
      Merge branch 'rds-ipv6' · 176bd861
      David S. Miller 提交于
      Ka-Cheong Poon says:
      
      ====================
      rds: IPv6 support
      
      This patch set adds IPv6 support to the kernel RDS and related
      modules.  Existing RDS apps using IPv4 address continue to run without
      any problem.  New RDS apps which want to use IPv6 address can do so by
      passing the address in struct sockaddr_in6 to bind(), connect() or
      sendmsg().  And those apps also need to use the new IPv6 equivalents
      of some of the existing socket options as the existing options use a
      32 bit integer to store IP address.
      
      All RDS code now use struct in6_addr to store IP address.  IPv4
      address is stored as an IPv4 mapped address.
      
      Header file changes
      
      There are many data structures (RDS socket options) used by RDS apps
      which use a 32 bit integer to store IP address. To support IPv6,
      struct in6_addr needs to be used. To ensure backward compatibility, a
      new data structure is introduced for each of those data structures
      which use a 32 bit integer to represent an IP address. And new socket
      options are introduced to use those new structures. This means that
      existing apps should work without a problem with the new RDS module.
      For apps which want to use IPv6, those new data structures and socket
      options can be used. IPv4 mapped address is used to represent IPv4
      address in the new data structures.
      
      Internally, all RDS data structures which contain an IP address are
      changed to use struct in6_addr to store the address. IPv4 address is
      stored as an IPv4 mapped address. All the functions which take an IP
      address as argument are also changed to use struct in6_addr.
      
      RDS/RDMA/IB uses a private data (struct rds_ib_connect_private)
      exchange between endpoints at RDS connection establishment time to
      support RDMA. This private data exchange uses a 32 bit integer to
      represent an IP address. This needs to be changed in order to support
      IPv6. A new private data struct rds6_ib_connect_private is introduced
      to handle this. To ensure backward compatibility, an IPv6 capable RDS
      stack uses another RDMA listener port (RDS_CM_PORT) to accept IPv6
      connection. And it continues to use the original RDS_PORT for IPv4 RDS
      connections. When it needs to communicate with an IPv6 peer, it uses
      the RDS_TCP_PORT to send the connection set up request.
      
      RDS/TCP changes
      
      TCP related code is changed to support IPv6.  Note that only an IPv6
      TCP listener on port RDS_TCP_PORT is created as it can accept both
      IPv4 and IPv6 connection requests.
      
      IB/RDMA changes
      
      The initial private data exchange between IB endpoints using RDMA is
      changed to support IPv6 address instead, if the peer address is IPv6.
      To ensure backward compatibility, annother RDMA listener port
      (RDS_CM_PORT) is used to accept IPv6 connection. An IPv6 capable RDS
      module continues to use the original RDS_PORT for IPv4 RDS
      connections. When it needs to communicate with an IPv6 peer, it uses
      the RDS_CM_PORT to send the connection set up request.
      ====================
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      176bd861
    • K
      rds: Extend RDS API for IPv6 support · b7ff8b10
      Ka-Cheong Poon 提交于
      There are many data structures (RDS socket options) used by RDS apps
      which use a 32 bit integer to store IP address. To support IPv6,
      struct in6_addr needs to be used. To ensure backward compatibility, a
      new data structure is introduced for each of those data structures
      which use a 32 bit integer to represent an IP address. And new socket
      options are introduced to use those new structures. This means that
      existing apps should work without a problem with the new RDS module.
      For apps which want to use IPv6, those new data structures and socket
      options can be used. IPv4 mapped address is used to represent IPv4
      address in the new data structures.
      
      v4: Revert changes to SO_RDS_TRANSPORT
      Signed-off-by: NKa-Cheong Poon <ka-cheong.poon@oracle.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b7ff8b10
    • K
      rds: Enable RDS IPv6 support · 1e2b44e7
      Ka-Cheong Poon 提交于
      This patch enables RDS to use IPv6 addresses. For RDS/TCP, the
      listener is now an IPv6 endpoint which accepts both IPv4 and IPv6
      connection requests.  RDS/RDMA/IB uses a private data (struct
      rds_ib_connect_private) exchange between endpoints at RDS connection
      establishment time to support RDMA. This private data exchange uses a
      32 bit integer to represent an IP address. This needs to be changed in
      order to support IPv6. A new private data struct
      rds6_ib_connect_private is introduced to handle this. To ensure
      backward compatibility, an IPv6 capable RDS stack uses another RDMA
      listener port (RDS_CM_PORT) to accept IPv6 connection. And it
      continues to use the original RDS_PORT for IPv4 RDS connections. When
      it needs to communicate with an IPv6 peer, it uses the RDS_CM_PORT to
      send the connection set up request.
      
      v5: Fixed syntax problem (David Miller).
      
      v4: Changed port history comments in rds.h (Sowmini Varadhan).
      
      v3: Added support to set up IPv4 connection using mapped address
          (David Miller).
          Added support to set up connection between link local and non-link
          addresses.
          Various review comments from Santosh Shilimkar and Sowmini Varadhan.
      
      v2: Fixed bound and peer address scope mismatched issue.
          Added back rds_connect() IPv6 changes.
      Signed-off-by: NKa-Cheong Poon <ka-cheong.poon@oracle.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1e2b44e7
    • K
      rds: Changing IP address internal representation to struct in6_addr · eee2fa6a
      Ka-Cheong Poon 提交于
      This patch changes the internal representation of an IP address to use
      struct in6_addr.  IPv4 address is stored as an IPv4 mapped address.
      All the functions which take an IP address as argument are also
      changed to use struct in6_addr.  But RDS socket layer is not modified
      such that it still does not accept IPv6 address from an application.
      And RDS layer does not accept nor initiate IPv6 connections.
      
      v2: Fixed sparse warnings.
      Signed-off-by: NKa-Cheong Poon <ka-cheong.poon@oracle.com>
      Acked-by: NSantosh Shilimkar <santosh.shilimkar@oracle.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      eee2fa6a