1. 13 12月, 2006 2 次提交
    • S
      RDMA/cma: Remove unneeded qp_type parameter from rdma_cm · 9b2e9c0c
      Sean Hefty 提交于
      The qp_type parameter into the rdma_cm is unneeded, and can be
      misleading.  The QP type should be determined from the port space.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      9b2e9c0c
    • R
      IB/fmr: ib_flush_fmr_pool() may wait too long · f47e22c6
      Roland Dreier 提交于
      ib_flush_fmr_pool() stashes away the request generation number
      properly, but then goes ahead and rereads it every time it tests
      whether the flush generation number has caught up.  This means that
      there is a theoretical possibility of livelock, if the request
      generation number keeps getting bumped and the flush generation number
      never catches up.  The fix is simple: use the request generation
      number read at the beginning of the function.
      
      Also, atomic_inc() followed by atomic_read() can be replaced with
      atomic_int_return().  There's no real requirement for atomicity here
      but we might as well shrink the code.
      
      This bug was discovered using David Binderman's list of "set but never
      used" warnings from icc.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      f47e22c6
  2. 09 12月, 2006 1 次提交
  3. 30 11月, 2006 16 次提交
  4. 22 11月, 2006 1 次提交
  5. 14 11月, 2006 1 次提交
    • R
      IB/mad: Fix race between cancel and receive completion · 39798695
      Roland Dreier 提交于
      When ib_cancel_mad() is called, it puts the canceled send on a list
      and schedules a "flushed" callback from process context.  However,
      this leaves a window where a receive completion could be processed
      before the send is fully flushed.
      
      This is fine, except that ib_find_send_mad() will find the MAD and
      return it to the receive processing, which results in the sender
      getting both a successful receive and a "flushed" send completion for
      the same request.  Understandably, this confuses the sender, which is
      expecting only one of these two callbacks, and leads to grief such as
      a use-after-free in IPoIB.
      
      Fix this by changing ib_find_send_mad() to return a send struct only
      if the status is still successful (and not "flushed").  The search of
      the send_list already had this check, so this patch just adds the same
      check to the search of the wait_list.
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      39798695
  6. 03 11月, 2006 1 次提交
  7. 31 10月, 2006 2 次提交
  8. 11 10月, 2006 2 次提交
    • S
      IB/cm: Send DREP in response to unmatched DREQ · 82a9c16a
      Sean Hefty 提交于
      Currently a DREP is only sent in response to a DREQ if a connection
      has been found matching the DREQ, and it is in the proper state.  Once
      a DREP is sent, the local connection moves into timewait.  Duplicate
      DREQs received while in this state result in re-sending the DREP.
      
      However, it's likely that the local connection will enter and exit
      timewait before the remote side times out a lost DREP and resends a DREQ.
      To handle this, we send a DREP in response to a DREQ, even if a local
      connection is not found.  This avoids maintaining disconnected
      id's in timewait states for excessively long times, just to handle a
      lost DREP.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      82a9c16a
    • S
      IB/cm: Fix timewait crash after module unload · 8575329d
      Sean Hefty 提交于
      If the ib_cm module is unloaded while id's are still in timewait, the
      CM will destroy the work queue used to process timewait.  Once the
      id's exit timewait, their timers will fire, leading to a crash trying
      to access the destroyed work queue.
      
      We need to track id's that are in timewait, and cancel their deferred
      work on module unload.
      Signed-off-by: NSean Hefty <sean.hefty@intel.com>
      Signed-off-by: NRoland Dreier <rolandd@cisco.com>
      8575329d
  9. 03 10月, 2006 5 次提交
  10. 29 9月, 2006 1 次提交
  11. 27 9月, 2006 1 次提交
  12. 24 9月, 2006 1 次提交
  13. 23 9月, 2006 6 次提交