1. 23 8月, 2016 1 次提交
  2. 04 8月, 2016 1 次提交
    • A
      IB/core: Support for CMA multicast join flags · ab15c95a
      Alex Vesker 提交于
      Added UCMA and CMA support for multicast join flags. Flags are
      passed using UCMA CM join command previously reserved fields.
      Currently supporting two join flags indicating two different
      multicast JoinStates:
      
      1. Full Member:
         The initiator creates the Multicast group(MCG) if it wasn't
         previously created, can send Multicast messages to the group
         and receive messages from the MCG.
      
      2. Send Only Full Member:
         The initiator creates the Multicast group(MCG) if it wasn't
         previously created, can send Multicast messages to the group
         but doesn't receive any messages from the MCG.
      
         IB: Send Only Full Member requires a query of ClassPortInfo
             to determine if SM/SA supports this option. If SM/SA
             doesn't support Send-Only there will be no join request
             sent and an error will be returned.
      
         ETH: When Send Only Full Member is requested no IGMP join
      	will be sent.
      Signed-off-by: NAlex Vesker <valex@mellanox.com>
      Reviewed by: Hal Rosenstock <hal@mellanox.com>
      Signed-off-by: NLeon Romanovsky <leon@kernel.org>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      ab15c95a
  3. 23 6月, 2016 1 次提交
  4. 18 6月, 2016 1 次提交
    • B
      IB/cma: Make the code easier to verify · 37e07cda
      Bart Van Assche 提交于
      Static source code analysis tools like smatch cannot handle functions
      that lock or not lock a mutex depending on the value of the arguments.
      Hence inline the function cma_disable_callback(). Additionally, this
      patch realizes a small performance optimization by reducing the number of
      mutex_lock() and mutex_unlock() calls in the modified functions. With
      this patch applied smatch no longer complains about source file cma.c.
      Without this patch smatch reports the following for this source file:
      
      drivers/infiniband/core/cma.c:1959: cma_req_handler() warn: inconsistent returns 'mutex:&listen_id->handler_mutex'.
        Locked on:   line 1880
                     line 1959
        Unlocked on: line 1941
      drivers/infiniband/core/cma.c:2112: iw_conn_req_handler() warn: inconsistent returns 'mutex:&listen_id->handler_mutex'.
        Locked on:   line 2048
        Unlocked on: line 2112
      Signed-off-by: NBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Sean Hefty <sean.hefty@intel.com>
      Cc: Steve Wise <swise@opengridcomputing.com>
      Cc: Leon Romanovsky <leonro@mellanox.com>
      Acked-by: NSean Hefty <sean.hefty@intel.com>
      Reviewed-by: NSteve Wise <swise@opengridcomputing.com>
      Reviewed-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      37e07cda
  5. 14 5月, 2016 1 次提交
  6. 13 5月, 2016 1 次提交
  7. 03 3月, 2016 1 次提交
  8. 02 3月, 2016 1 次提交
    • H
      IB/cma: Print warning on different inner and header P_Keys · 84424a7f
      Haggai Eran 提交于
      Commit 4c21b5bc ("IB/cma: Add net_dev and private data checks to RDMA
      CM") added checks for incoming RDMA CM requests that they can be matched to
      a netdev based on the P_Key in the BTH of the request. This behavior was
      reverted in commit ab3964ad ("IB/cma: Use inner P_Key to determine
      netdev"), since the mlx5 and ipath drivers didn't send the correct value
      in the BTH P_Key.
      
      Since the ipath driver was removed, and the mlx5 driver can now send GSI
      packets on different P_Keys, we could revert the patch to let the rdma_cm
      module look on the BTH P_Key when deciding to what netdev a packet belongs.
      However, that still breaks compatibility with the older drivers.
      
      Change the behavior to print a warning when receiving a request that has a
      different BTH P_Key and inner payload P_Key. In the future, after users
      have seen the warnings and upgraded their setups, remove the warning and
      block these requests.
      Signed-off-by: NHaggai Eran <haggaie@mellanox.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      84424a7f
  9. 20 1月, 2016 2 次提交
  10. 23 12月, 2015 9 次提交
  11. 09 12月, 2015 1 次提交
  12. 31 10月, 2015 1 次提交
  13. 29 10月, 2015 3 次提交
  14. 22 10月, 2015 4 次提交
  15. 21 10月, 2015 2 次提交
  16. 07 10月, 2015 1 次提交
  17. 31 8月, 2015 8 次提交
  18. 29 8月, 2015 1 次提交
    • S
      RDMA/cma: fix IPv6 address resolution · 6c26a771
      Spencer Baugh 提交于
      Resolving a link-local IPv6 address with an unspecified source address
      was broken by commit 5462eddd, which prevented the IPv6 stack from
      learning the scope id of the link-local IPv6 address, causing random
      failures as the IP stack chose a random link to resolve the address on.
      
      This commit 5462eddd made us bail out of cma_check_linklocal early if
      the address passed in was not an IPv6 link-local address. On the address
      resolution path, the address passed in is the source address; if the
      source address is the unspecified address, which is not link-local, we
      will bail out early.
      
      This is mostly correct, but if the destination address is a link-local
      address, then we will be following a link-local route, and we'll need to
      tell the IPv6 stack what the scope id of the destination address is.
      This used to be done by last line of cma_check_linklocal, which is
      skipped when bailing out early:
      
      	dev_addr->bound_dev_if = sin6->sin6_scope_id;
      
      (In cma_bind_addr, the sin6_scope_id of the source address is set to the
      sin6_scope_id of the destination address, so this is correct)
      This line is required in turn for the following line, L279 of
      addr6_resolve, to actually inform the IPv6 stack of the scope id:
      
            fl6.flowi6_oif = addr->bound_dev_if;
      
      Since we can only know we are in this failure case when we have access
      to both the source IPv6 address and destination IPv6 address, we have to
      deal with this further up the stack. So detect this failure case in
      cma_bind_addr, and set bound_dev_if to the destination address scope id
      to correct it.
      Signed-off-by: NSpencer Baugh <sbaugh@catern.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      6c26a771