1. 20 4月, 2008 4 次提交
    • T
      SUNRPC: Fix read ordering problems with req->rq_private_buf.len · 1e799b67
      Trond Myklebust 提交于
      We want to ensure that req->rq_private_buf.len is updated before
      req->rq_received, so that call_decode() doesn't use an old value for
      req->rq_rcv_buf.len.
      
      In 'call_decode()' itself, instead of using task->tk_status (which is set
      using req->rq_received) must use the actual value of
      req->rq_private_buf.len when deciding whether or not the received RPC reply
      is too short.
      
      Finally ensure that we set req->rq_rcv_buf.len to zero when retrying a
      request. A typo meant that we were resetting req->rq_private_buf.len in
      call_decode(), and then clobbering that value with the old rq_rcv_buf.len
      again in xprt_transmit().
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      1e799b67
    • T
      SUNRPC: Don't attempt to destroy expired RPCSEC_GSS credentials.. · 080a1f14
      Trond Myklebust 提交于
      ..and always destroy using a 'soft' RPC call. Destroying GSS credentials
      isn't mandatory; the server can always cope with a few credentials not
      getting destroyed in a timely fashion.
      
      This actually fixes a hang situation. Basically, some servers will decide
      that the client is crazy if it tries to destroy an RPC context for which
      they have sent an RPCSEC_GSS_CREDPROBLEM, and so will refuse to talk to it
      for a while.
      The regression therefor probably was introduced by commit
      0df7fb74.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      080a1f14
    • T
      SUNRPC: Fix up xprt_write_space() · b6ddf64f
      Trond Myklebust 提交于
      The rest of the networking layer uses SOCK_ASYNC_NOSPACE to signal whether
      or not we have someone waiting for buffer memory. Convert the SUNRPC layer
      to use the same idiom.
      Remove the unlikely()s in xs_udp_write_space and xs_tcp_write_space. In
      fact, the most common case will be that there is nobody waiting for buffer
      space.
      
      SOCK_NOSPACE is there to tell the TCP layer whether or not the cwnd was
      limited by the application window. Ensure that we follow the same idiom as
      the rest of the networking layer here too.
      
      Finally, ensure that we clear SOCK_ASYNC_NOSPACE once we wake up, so that
      write_space() doesn't keep waking things up on xprt->pending.
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      b6ddf64f
    • T
      SUNRPC: Fix a bug in call_decode() · 24b74bf0
      Trond Myklebust 提交于
      call_verify() can, under certain circumstances, free the RPC slot. In that
      case, our cached pointer 'req = task->tk_rqstp' is invalid. Bug was
      introduced in commit 220bcc2a (SUNRPC:
      Don't call xprt_release in call refresh).
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      24b74bf0
  2. 15 3月, 2008 6 次提交
  3. 13 3月, 2008 2 次提交
  4. 08 3月, 2008 1 次提交
  5. 29 2月, 2008 7 次提交
  6. 26 2月, 2008 5 次提交
  7. 22 2月, 2008 1 次提交
  8. 15 2月, 2008 3 次提交
  9. 14 2月, 2008 1 次提交
    • R
      docbook: sunrpc filenames and notation fixes · 65b6e42c
      Randy Dunlap 提交于
      Use updated file list for docbook files and
      fix kernel-doc warnings in sunrpc:
      Warning(linux-2.6.24-git12//net/sunrpc/rpc_pipe.c:689): No description found for parameter 'rpc_client'
      Warning(linux-2.6.24-git12//net/sunrpc/rpc_pipe.c:765): No description found for parameter 'flags'
      Warning(linux-2.6.24-git12//net/sunrpc/clnt.c:584): No description found for parameter 'tk_ops'
      Warning(linux-2.6.24-git12//net/sunrpc/clnt.c:618): No description found for parameter 'bufsize'
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Cc: Trond Myklebust <trond.myklebust@fys.uio.no>
      Cc: "J. Bruce Fields" <bfields@fieldses.org>
      Cc: Neil Brown <neilb@suse.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      65b6e42c
  10. 11 2月, 2008 1 次提交
  11. 02 2月, 2008 9 次提交