Searched hist:"1 e799b67" (Results 1 – 2 of 2) sorted by relevance
/openbmc/linux/net/sunrpc/ |
H A D | xprt.c | 1e799b67 Fri Mar 21 15:19:41 CDT 2008 Trond Myklebust <Trond.Myklebust@netapp.com> 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> 1e799b67 Fri Mar 21 15:19:41 CDT 2008 Trond Myklebust <Trond.Myklebust@netapp.com> 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>
|
H A D | clnt.c | 1e799b67 Fri Mar 21 15:19:41 CDT 2008 Trond Myklebust <Trond.Myklebust@netapp.com> 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> 1e799b67 Fri Mar 21 15:19:41 CDT 2008 Trond Myklebust <Trond.Myklebust@netapp.com> 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>
|