1. 11 8月, 2015 1 次提交
  2. 13 6月, 2015 9 次提交
  3. 05 6月, 2015 2 次提交
  4. 31 3月, 2015 11 次提交
  5. 24 2月, 2015 1 次提交
    • C
      xprtrdma: Store RDMA credits in unsigned variables · 9b1dcbc8
      Chuck Lever 提交于
      Dan Carpenter's static checker pointed out:
      
         net/sunrpc/xprtrdma/rpc_rdma.c:879 rpcrdma_reply_handler()
         warn: can 'credits' be negative?
      
      "credits" is defined as an int. The credits value comes from the
      server as a 32-bit unsigned integer.
      
      A malicious or broken server can plant a large unsigned integer in
      that field which would result in an underflow in the following
      logic, potentially triggering a deadlock of the mount point by
      blocking the client from issuing more RPC requests.
      
      net/sunrpc/xprtrdma/rpc_rdma.c:
      
        876          credits = be32_to_cpu(headerp->rm_credit);
        877          if (credits == 0)
        878                  credits = 1;    /* don't deadlock */
        879          else if (credits > r_xprt->rx_buf.rb_max_requests)
        880                  credits = r_xprt->rx_buf.rb_max_requests;
        881
        882          cwnd = xprt->cwnd;
        883          xprt->cwnd = credits << RPC_CWNDSHIFT;
        884          if (xprt->cwnd > cwnd)
        885                  xprt_release_rqst_cong(rqst->rq_task);
      Reported-by: NDan Carpenter <dan.carpenter@oracle.com>
      Fixes: eba8ff66 ("xprtrdma: Move credit update to RPC . . .")
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      9b1dcbc8
  6. 06 2月, 2015 1 次提交
  7. 30 1月, 2015 14 次提交
  8. 26 11月, 2014 1 次提交
    • C
      xprtrdma: Cap req_cqinit · e7104a2a
      Chuck Lever 提交于
      Recent work made FRMR registration and invalidation completions
      unsignaled. This greatly reduces the adapter interrupt rate.
      
      Every so often, however, a posted send Work Request is allowed to
      signal. Otherwise, the provider's Work Queue will wrap and the
      workload will hang.
      
      The number of Work Requests that are allowed to remain unsignaled is
      determined by the value of req_cqinit. Currently, this is set to the
      size of the send Work Queue divided by two, minus 1.
      
      For FRMR, the send Work Queue is the maximum number of concurrent
      RPCs (currently 32) times the maximum number of Work Requests an
      RPC might use (currently 7, though some adapters may need more).
      
      For mlx4, this is 224 entries. This leaves completion signaling
      disabled for 111 send Work Requests.
      
      Some providers hold back dispatching Work Requests until a CQE is
      generated.  If completions are disabled, then no CQEs are generated
      for quite some time, and that can stall the Work Queue.
      
      I've seen this occur running xfstests generic/113 over NFSv4, where
      eventually, posting a FAST_REG_MR Work Request fails with -ENOMEM
      because the Work Queue has overflowed. The connection is dropped
      and re-established.
      
      Cap the rep_cqinit setting so completions are not left turned off
      for too long.
      
      BugLink: https://bugzilla.linux-nfs.org/show_bug.cgi?id=269Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NAnna Schumaker <Anna.Schumaker@Netapp.com>
      e7104a2a