From: Tom Talpey <tom@talpey.com>
To: Chuck Lever <chuck.lever@oracle.com>,
linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org
Subject: Re: [PATCH v1 8/9] xprtrdma: Invalidate in the RPC reply handler
Date: Mon, 23 Nov 2015 20:01:14 -0500 [thread overview]
Message-ID: <5653B6DA.1080201@talpey.com> (raw)
In-Reply-To: <20151123221454.32702.76062.stgit@manet.1015granger.net>
On 11/23/2015 5:14 PM, Chuck Lever wrote:
> There is a window between the time the RPC reply handler wakes the
> waiting RPC task and when xprt_release() invokes ops->buf_free.
> During this time, memory regions containing the data payload may
> still be accessed by a broken or malicious server, but the RPC
> application has already been allowed access to the memory containing
> the RPC request's data payloads.
>
> The server should be fenced from client memory containing RPC data
> payloads _before_ the RPC application is allowed to continue.
No concern, just Hurray for implementing this fundamental
integrity requirement. It's even more important when krb5i
is in play, to avoid truly malicious injection-after-integrity.
>
> This change also more strongly enforces send queue accounting. There
> is a maximum number of RPC calls allowed to be outstanding. When an
> RPC/RDMA transport is set up, just enough send queue resources are
> allocated to handle registration, Send, and invalidation WRs for
> each those RPCs at the same time.
>
> Before, additional RPC calls could be dispatched while invalidation
> WRs were still consuming send WQEs. When invalidation WRs backed
> up, dispatching additional RPCs resulted in a send queue overrun.
>
> Now, the reply handler prevents RPC dispatch until invalidation is
> complete. This prevents RPC call dispatch until there are enough
> send queue resources to proceed.
>
> Still to do: If an RPC exits early (say, ^C), the reply handler has
> no opportunity to perform invalidation. Currently, xprt_rdma_free()
> still frees remaining RDMA resources, which could deadlock.
> Additional changes are needed to handle invalidation properly in this
> case.
>
> Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
> Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
> ---
> net/sunrpc/xprtrdma/rpc_rdma.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c
> index d7b9156..4ad72ca 100644
> --- a/net/sunrpc/xprtrdma/rpc_rdma.c
> +++ b/net/sunrpc/xprtrdma/rpc_rdma.c
> @@ -898,6 +898,16 @@ badheader:
> break;
> }
>
> + /* Invalidate and flush the data payloads before waking the
> + * waiting application. This guarantees the memory region is
> + * properly fenced from the server before the application
> + * accesses the data. It also ensures proper send flow
> + * control: waking the next RPC waits until this RPC has
> + * relinquished all its Send Queue entries.
> + */
> + if (req->rl_nchunks)
> + r_xprt->rx_ia.ri_ops->ro_unmap_sync(r_xprt, req);
> +
> credits = be32_to_cpu(headerp->rm_credit);
> if (credits == 0)
> credits = 1; /* don't deadlock */
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
next prev parent reply other threads:[~2015-11-24 1:01 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-23 22:13 [PATCH v1 0/9] NFS/RDMA client patches for 4.5 Chuck Lever
2015-11-23 22:13 ` [PATCH v1 1/9] xprtrdma: Add a safety margin for receive buffers Chuck Lever
2015-11-24 0:55 ` Tom Talpey
2015-11-24 1:16 ` Chuck Lever
2015-11-24 1:22 ` Tom Talpey
2015-11-24 1:44 ` Chuck Lever
2015-11-23 22:14 ` [PATCH v1 2/9] xprtrdma: Move struct ib_send_wr off the stack Chuck Lever
2015-11-23 22:14 ` [PATCH v1 3/9] xprtrdma: Introduce ro_unmap_sync method Chuck Lever
2015-11-24 6:45 ` Christoph Hellwig
2015-11-24 7:28 ` Jason Gunthorpe
2015-11-24 10:59 ` Sagi Grimberg
2015-11-24 13:43 ` Tom Talpey
2015-11-24 14:40 ` Sagi Grimberg
2015-11-24 14:39 ` Chuck Lever
2015-11-24 14:44 ` Sagi Grimberg
2015-11-24 15:20 ` Chuck Lever
2015-11-24 18:57 ` Jason Gunthorpe
2015-11-23 22:14 ` [PATCH v1 4/9] xprtrdma: Add ro_unmap_sync method for FRWR Chuck Lever
2015-11-23 22:14 ` [PATCH v1 5/9] xprtrdma: Add ro_unmap_sync method for FMR Chuck Lever
2015-11-24 0:57 ` Tom Talpey
2015-11-24 6:52 ` Future of FMR support, was: " Christoph Hellwig
2015-11-24 7:12 ` Jason Gunthorpe
2015-12-01 15:33 ` Chuck Lever
2015-12-02 12:27 ` Christoph Hellwig
2015-11-24 12:36 ` Tom Talpey
2015-11-24 21:54 ` santosh shilimkar
2015-11-25 9:00 ` Christoph Hellwig
2015-11-25 17:09 ` santosh shilimkar
2015-11-25 18:22 ` Or Gerlitz
2015-11-25 19:17 ` santosh shilimkar
2015-11-25 19:28 ` Jason Gunthorpe
2015-11-26 10:01 ` Sagi Grimberg
2015-11-23 22:14 ` [PATCH v1 6/9] xprtrdma: Add ro_unmap_sync method for all-physical registration Chuck Lever
2015-11-23 22:14 ` [PATCH v1 7/9] SUNRPC: Introduct xprt_commit_rqst() Chuck Lever
2015-11-24 19:54 ` Anna Schumaker
2015-11-24 19:56 ` Chuck Lever
2015-11-23 22:14 ` [PATCH v1 8/9] xprtrdma: Invalidate in the RPC reply handler Chuck Lever
2015-11-24 1:01 ` Tom Talpey [this message]
2015-11-23 22:15 ` [PATCH v1 9/9] xprtrdma: Revert commit e7104a2a9606 ('xprtrdma: Cap req_cqinit') Chuck Lever
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=5653B6DA.1080201@talpey.com \
--to=tom@talpey.com \
--cc=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).