1. 09 4月, 2009 1 次提交
    • Y
      RDMA/cma: Create cm id even when IB port is down · d2ca39f2
      Yossi Etigin 提交于
      When doing rdma_resolve_addr(), if the relevant IB port is down, the
      function fails and the cm_id is not bound to the correct device.
      Therefore, application does not have a device handle and cannot wait
      for the port to become active.  The function fails because the
      underlying IPoIB interface is not joined to the broadcast group and
      therefore the SA does not have a multicast record to take a Q_Key
      from.
      
      The fix is to use lazy Q_Key resolution - cma_set_qkey() will set
      id_priv->qkey if it was not set, and will be called just before the
      Q_Key is really required.
      Signed-off-by: NYossi Etigin <yosefe@voltaire.com>
      Acked-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      d2ca39f2
  2. 02 4月, 2009 1 次提交
  3. 25 12月, 2008 1 次提交
  4. 05 8月, 2008 1 次提交
    • R
      RDMA/cma: Remove padding arrays by using struct sockaddr_storage · 3f446754
      Roland Dreier 提交于
      There are a few places where the RDMA CM code handles IPv6 by doing
      
      	struct sockaddr		addr;
      	u8			pad[sizeof(struct sockaddr_in6) -
      				    sizeof(struct sockaddr)];
      
      This is fragile and ugly; handle this in a better way with just
      
      	struct sockaddr_storage	addr;
      
      [ Also roll in patch from Aleksey Senin <alekseys@voltaire.com> to
        switch to struct sockaddr_storage and get rid of padding arrays in
        struct rdma_addr. ]
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      3f446754
  5. 23 7月, 2008 2 次提交
  6. 15 7月, 2008 4 次提交
  7. 17 4月, 2008 1 次提交
  8. 31 3月, 2008 1 次提交
  9. 15 2月, 2008 1 次提交
    • S
      RDMA/cma: Do not issue MRA if user rejects connection request · ead595ae
      Sean Hefty 提交于
      There's an undesirable interaction with issuing MRA requests to
      increase connection timeouts and the listen backlog.
      
      When the rdma_cm receives a connection request, it queues an MRA with
      the ib_cm.  (The ib_cm will send an MRA if it receives a duplicate
      REQ.)  The rdma_cm will then create a new rdma_cm_id and give that to
      the user, which in this case is the rdma_user_cm.
      
      If the listen backlog maintained in the rdma_user_cm is full, it
      destroys the rdma_cm_id, which in turns destroys the ib_cm_id.  The
      ib_cm_id generates a REJ because the state of the ib_cm_id has changed
      to MRA sent, versus REQ received.  When the backlog is full, we just
      want to drop the REQ so that it is retried later.
      
      Fix this by deferring queuing the MRA until after the user of the
      rdma_cm has examined the connection request.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      ead595ae
  10. 29 1月, 2008 2 次提交
  11. 26 1月, 2008 4 次提交
  12. 19 10月, 2007 1 次提交
  13. 17 10月, 2007 2 次提交
    • S
      RDMA/cma: Fix deadlock destroying listen requests · d02d1f53
      Sean Hefty 提交于
      Deadlock condition reported by Kanoj Sarcar <kanoj@netxen.com>.
      The deadlock occurs when a connection request arrives at the same
      time that a wildcard listen is being destroyed.
      
      A wildcard listen maintains per device listen requests for each
      RDMA device in the system.  The per device listens are automatically
      added and removed when RDMA devices are inserted or removed from
      the system.
      
      When a wildcard listen is destroyed, rdma_destroy_id() acquires
      the rdma_cm's device mutex ('lock') to protect against hot-plug
      events adding or removing per device listens.  It then tries to
      destroy the per device listens by calling ib_destroy_cm_id() or
      iw_destroy_cm_id().  It does this while holding the device mutex.
      
      However, if the underlying iw/ib CM reports a connection request
      while this is occurring, the rdma_cm callback function will try
      to acquire the same device mutex.  Since we're in a callback,
      the ib_destroy_cm_id() or iw_destroy_cm_id() calls will block until
      their callback thread returns, but the callback is blocked waiting for
      the device mutex.
      
      Fix this by re-working how per device listens are destroyed.  Use
      rdma_destroy_id(), which avoids the deadlock, in place of
      cma_destroy_listen().  Additional synchronization is added to handle
      device hot-plug events and ensure that the id is not destroyed twice.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      d02d1f53
    • S
      RDMA/cma: Add locking around QP accesses · c5483388
      Sean Hefty 提交于
      If a user allocates a QP on an rdma_cm_id, the rdma_cm will automatically
      transition the QP through its states (RTR, RTS, error, etc.)  While the
      QP state transitions are occurring, the QP itself must remain valid.
      Provide locking around the QP pointer to prevent its destruction while
      accessing the pointer.
      
      This fixes an issue reported by Olaf Kirch from Oracle that resulted in
      a system crash:
      
      "An incoming connection arrives and we decide to tear down the nascent
       connection.  The remote ends decides to do the same.  We start to shut
       down the connection, and call rdma_destroy_qp on our cm_id. ... Now
       apparently a 'connect reject' message comes in from the other host,
       and cma_ib_handler() is called with an event of IB_CM_REJ_RECEIVED.
       It calls cma_modify_qp_err, which for some odd reason tries to modify
       the exact same QP we just destroyed."
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      c5483388
  14. 11 10月, 2007 1 次提交
  15. 10 10月, 2007 2 次提交
  16. 18 7月, 2007 1 次提交
  17. 11 7月, 2007 1 次提交
  18. 08 6月, 2007 1 次提交
  19. 15 5月, 2007 3 次提交
  20. 07 3月, 2007 1 次提交
  21. 23 2月, 2007 2 次提交
  22. 17 2月, 2007 1 次提交
    • S
      RDMA/cma: Add multicast communication support · c8f6a362
      Sean Hefty 提交于
      Extend rdma_cm to support multicast communication.  Multicast support
      is added to the existing RDMA_PS_UDP port space, as well as a new
      RDMA_PS_IPOIB port space.  The latter port space allows joining the
      multicast groups used by IPoIB, which enables offloading IPoIB traffic
      to a separate QP.  The port space determines the signature used in the
      MGID when joining the group.  The newly added RDMA_PS_IPOIB also
      allows for unicast operations, similar to RDMA_PS_UDP.
      
      Supporting the RDMA_PS_IPOIB requires changing how UD QPs are initialized,
      since we can no longer assume that the qkey is constant.  This requires
      saving the Q_Key to use when attaching to a device, so that it is
      available when creating the QP.  The Q_Key information is exported to
      the user through the existing rdma_init_qp_attr() interface.
      
      Multicast support is also exported to userspace through the rdma_ucm.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      c8f6a362
  23. 11 2月, 2007 2 次提交
  24. 08 1月, 2007 1 次提交
  25. 13 12月, 2006 2 次提交