On 31 Aug 2022, at 18:44, Benjamin Coddington wrote: > On 31 Aug 2022, at 17:34, Trond Myklebust wrote: > >> On Wed, 2022-08-31 at 16:20 -0400, Benjamin Coddington wrote: >>> 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? >>> >> >> How about this? > > I think that will fix it. I'll test it overnight and see what happens. On a second look, I'm not sure this will fix it, because I don't think its a memory-barrier problem, rather its that setting the two buffer's bvec = NULL is not atomic. Meanwhile, I am testing your patch. Ben
