1. 28 Jul, 2020 3 commits
    • Chuck Lever's avatar
      svcrdma: CM event handler clean up · b297fed6
      Chuck Lever authored
      Now that there's a core tracepoint that reports these events, there's
      no need to maintain dprintk() call sites in each arm of the switch
      statements.
      
      We also refresh the documenting comments.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      b297fed6
    • Chuck Lever's avatar
      svcrdma: Remove transport reference counting · 365e9992
      Chuck Lever authored
      Jason tells me that a ULP cannot rely on getting an ESTABLISHED
      and DISCONNECTED event pair for each connection, so transport
      reference counting in the CM event handler will never be reliable.
      
      Now that we have ib_drain_qp(), svcrdma should no longer need to
      hold transport references while Sends and Receives are posted. So
      remove the get/put call sites in the CM event handlers.
      
      This eliminates a significant source of locked memory bus traffic.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      365e9992
    • Chuck Lever's avatar
      svcrdma: Fix another Receive buffer leak · 64d26422
      Chuck Lever authored
      During a connection tear down, the Receive queue is flushed before
      the device resources are freed. Typically, all the Receives flush
      with IB_WR_FLUSH_ERR.
      
      However, any pending successful Receives flush with IB_WR_SUCCESS,
      and the server automatically posts a fresh Receive to replace the
      completing one. This happens even after the connection has closed
      and the RQ is drained. Receives that are posted after the RQ is
      drained appear never to complete, causing a Receive resource leak.
      The leaked Receive buffer is left DMA-mapped.
      
      To prevent these late-posted recv_ctxt's from leaking, block new
      Receive posting after XPT_CLOSE is set.
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      64d26422
  2. 26 Jul, 2020 1 commit
  3. 24 Jul, 2020 2 commits
  4. 13 Jul, 2020 32 commits
  5. 12 Jul, 2020 2 commits