client call_decode WARN_ON memcmp race since 72691a269f0b

["Benjamin Coddington" <bcodding@xxxxxxxxxx>]

Hey Trond,

Since "72691a269f0b SUNRPC: Don't reuse bvec on retransmission of the
request" I can sometimes pop the WARN_ON() in call_decode(), usually on
generic/642.

I think there's a kworker halfway through

xprt_complete_rqst() ->
       xprt_request_dequeue_receive_locked()

between these two linse:
         xdr_free_bvec(&req->rq_rcv_buf);
         req->rq_private_buf.bvec = NULL;

And at the same time the task is doing the WARN_ON(memcmp()) in
call_decode.

I'm not sure of a good fix - perhaps we can fixup the other paths that
require the NULL check in xdr_alloc_bvec() so we don't have to set bvec =
NULL.

Any thoughts?

Ben