SUNRPC: Fix read ordering problems with req->rq_private_buf.len
authorTrond Myklebust <Trond.Myklebust@netapp.com>
Fri, 21 Mar 2008 20:19:41 +0000 (16:19 -0400)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Sat, 19 Apr 2008 20:53:20 +0000 (16:53 -0400)
commit1e799b673c6b82b336ab13c48b5651d511ca3000
tree9954155b2a9bdd72e49a078418ceea6c47bcc609
parentc1d519312dcdf11532fed9f99a8ecc3547ffd9d6
SUNRPC: Fix read ordering problems with req->rq_private_buf.len

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: Trond Myklebust <Trond.Myklebust@netapp.com>
net/sunrpc/clnt.c
net/sunrpc/xprt.c