From: Chuck Lever <chuck.lever@oracle.com>
To: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: [PATCH v1 1/7] xprtrdma: Properly recover FRWRs with in-flight FASTREG WRs
Date: Thu, 26 Jan 2017 12:55:39 -0500 [thread overview]
Message-ID: <20170126175539.5794.5426.stgit@manet.1015granger.net> (raw)
In-Reply-To: <20170126174806.5794.14678.stgit@manet.1015granger.net>
Sriharsha (sriharsha.basavapatna@broadcom.com) reports an occasional
double DMA unmap of an FRWR MR when a connection is lost. I see one
way this can happen.
When a request requires more than one segment or chunk,
rpcrdma_marshal_req loops, invoking ->frwr_op_map for each segment
(MR) in each chunk. Each call posts a FASTREG Work Request to
register one MR.
Now suppose that the transport connection is lost part-way through
marshaling this request. As part of recovering and resetting that
req, rpcrdma_marshal_req invokes ->frwr_op_unmap_safe, which hands
all the req's registered FRWRs to the MR recovery thread.
But note: FRWR registration is asynchronous. So it's possible that
some of these "already registered" FRWRs are fully registered, and
some are still waiting for their FASTREG WR to complete.
When the connection is lost, the "already registered" frmrs are
marked FRMR_IS_VALID, and the "still waiting" WRs flush. Then
frwr_wc_fastreg marks these frmrs FRMR_FLUSHED_FR.
But thanks to ->frwr_op_unmap_safe, the MR recovery thread is doing
an unreg / alloc_mr, a DMA unmap, and marking each of these frwrs
FRMR_IS_INVALID, at the same time frwr_wc_fastreg might be running.
- If the recovery thread runs last, then the frmr is marked
FRMR_IS_INVALID, and life continues.
- If frwr_wc_fastreg runs last, the frmr is marked FRMR_FLUSHED_FR,
but the recovery thread has already DMA unmapped that MR. When
->frwr_op_map later re-uses this frmr, it sees it is not marked
FRMR_IS_INVALID, and tries to recover it before using it, resulting
in a second DMA unmap of the same MR.
The fix is to guarantee in-flight FASTREG WRs have flushed before MR
recovery runs on those FRWRs. It's safe to wait until the RPC is
retransmitted.
Reported-by: Sriharsha Basavapatna <sriharsha.basavapatna@broadcom.com>
Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
---
net/sunrpc/xprtrdma/rpc_rdma.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
index d889883..0ce7a7b 100644
--- a/net/sunrpc/xprtrdma/rpc_rdma.c
+++ b/net/sunrpc/xprtrdma/rpc_rdma.c
@@ -781,7 +781,6 @@ static bool rpcrdma_results_inline(struct rpcrdma_xprt *r_xprt,
return 0;
out_unmap:
- r_xprt->rx_ia.ri_ops->ro_unmap_safe(r_xprt, req, false);
return PTR_ERR(iptr);
}
next prev parent reply other threads:[~2017-01-26 17:56 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-26 17:55 [PATCH v1 0/7] NFS/RDMA client-side patches for 4.11 Chuck Lever
2017-01-26 17:55 ` Chuck Lever [this message]
2017-01-26 17:55 ` [PATCH v1 2/7] xprtrdma: Handle stale connection rejection Chuck Lever
2017-01-26 17:55 ` [PATCH v1 3/7] xprtrdma: Refactor management of mw_list field Chuck Lever
2017-01-26 17:56 ` [PATCH v1 4/7] sunrpc: Allow xprt->ops->timer method to sleep Chuck Lever
2017-01-26 17:56 ` [PATCH v1 5/7] sunrpc: Enable calls to rpc_call_null_helper() from other modules Chuck Lever
2017-01-27 22:07 ` Anna Schumaker
2017-01-27 22:10 ` Chuck Lever
2017-01-26 17:56 ` [PATCH v1 6/7] xprtrdma: Detect unreachable NFS/RDMA servers more reliably Chuck Lever
2017-01-26 17:56 ` [PATCH v1 7/7] sunrpc: Allow keepalive ping on a credit-full transport Chuck Lever
2017-01-30 20:29 ` Anna Schumaker
2017-01-30 20:32 ` Chuck Lever
2017-01-30 21:36 ` Anna Schumaker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170126175539.5794.5426.stgit@manet.1015granger.net \
--to=chuck.lever@oracle.com \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).