Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Benjamin Coddington" <bcodding@redhat.com>
To:     "Trond Myklebust" <trondmy@hammerspace.com>
Cc:     "Linux NFS Mailing List" <linux-nfs@vger.kernel.org>
Subject: client call_decode WARN_ON memcmp race since 72691a269f0b
Date:   Wed, 31 Aug 2022 16:20:55 -0400
Message-ID: <6806AB48-F7D6-4639-8D03-E31BA25C4CF3@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: bulk

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