1. 01 5月, 2007 2 次提交
    • C
      SUNRPC: Eliminate side effects from rpc_malloc · c5a4dd8b
      Chuck Lever 提交于
      Currently rpc_malloc sets req->rq_buffer internally.  Make this a more
      generic interface:  return a pointer to the new buffer (or NULL) and
      make the caller set req->rq_buffer and req->rq_bufsize.  This looks much
      more like kmalloc and eliminates the side effects.
      
      To fix a potential deadlock, this patch also replaces GFP_NOFS with
      GFP_NOWAIT in rpc_malloc.  This prevents async RPCs from sleeping outside
      the RPC's task scheduler while allocating their buffer.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      c5a4dd8b
    • C
      SUNRPC: RPC buffer size estimates are too large · 2bea90d4
      Chuck Lever 提交于
      The RPC buffer size estimation logic in net/sunrpc/clnt.c always
      significantly overestimates the requirements for the buffer size.
      A little instrumentation demonstrated that in fact rpc_malloc was never
      allocating the buffer from the mempool, but almost always called kmalloc.
      
      To compute the size of the RPC buffer more precisely, split p_bufsiz into
      two fields; one for the argument size, and one for the result size.
      
      Then, compute the sum of the exact call and reply header sizes, and split
      the RPC buffer precisely between the two.  That should keep almost all RPC
      buffers within the 2KiB buffer mempool limit.
      
      And, we can finally be rid of RPC_SLACK_SPACE!
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      2bea90d4
  2. 21 4月, 2007 1 次提交
    • T
      RPC: Fix the TCP resend semantics for NFSv4 · 241c39b9
      Trond Myklebust 提交于
      Fix a regression due to the patch "NFS: disconnect before retrying NFSv4
      requests over TCP"
      
      The assumption made in xprt_transmit() that the condition
      	"req->rq_bytes_sent == 0 and request is on the receive list"
      should imply that we're dealing with a retransmission is false.
      Firstly, it may simply happen that the socket send queue was full
      at the time the request was initially sent through xprt_transmit().
      Secondly, doing this for each request that was retransmitted implies
      that we disconnect and reconnect for _every_ request that happened to
      be retransmitted irrespective of whether or not a disconnection has
      already occurred.
      
      Fix is to move this logic into the call_status request timeout handler.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      241c39b9
  3. 13 2月, 2007 1 次提交
  4. 11 2月, 2007 1 次提交
  5. 04 2月, 2007 2 次提交
  6. 25 1月, 2007 1 次提交
  7. 06 12月, 2006 6 次提交
  8. 03 12月, 2006 1 次提交
  9. 02 10月, 2006 1 次提交
  10. 29 9月, 2006 1 次提交
  11. 23 9月, 2006 12 次提交
  12. 25 8月, 2006 3 次提交
  13. 04 8月, 2006 1 次提交
  14. 22 7月, 2006 1 次提交
  15. 21 3月, 2006 6 次提交