From: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> To: linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org Subject: [PATCH v3 22/25] xprtrdma: No direct data placement with krb5i and krb5p Date: Mon, 20 Jun 2016 12:11:35 -0400 [thread overview] Message-ID: <20160620161135.10809.55145.stgit@manet.1015granger.net> (raw) In-Reply-To: <20160620155751.10809.22262.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org> Direct data placement is not allowed when using flavors that guarantee integrity or privacy. When such security flavors are in effect, don't allow the use of Read and Write chunks for moving individual data items. All messages larger than the inline threshold are sent via Long Call or Long Reply. On my systems (CX-3 Pro on FDR), for small I/O operations, the use of Long messages adds only around 5 usecs of latency in each direction. Note that when integrity or encryption is used, the host CPU touches every byte in these messages. Even if it could be used, data movement offload doesn't buy much in this case. Signed-off-by: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> --- include/linux/sunrpc/auth.h | 3 +++ include/linux/sunrpc/gss_api.h | 2 ++ net/sunrpc/auth_gss/auth_gss.c | 2 ++ net/sunrpc/auth_gss/gss_krb5_mech.c | 2 ++ net/sunrpc/auth_gss/gss_mech_switch.c | 12 ++++++++++++ net/sunrpc/xprtrdma/rpc_rdma.c | 12 ++++++++++-- 6 files changed, 31 insertions(+), 2 deletions(-) diff --git a/include/linux/sunrpc/auth.h b/include/linux/sunrpc/auth.h index 8997915..3a40287 100644 --- a/include/linux/sunrpc/auth.h +++ b/include/linux/sunrpc/auth.h @@ -107,6 +107,9 @@ struct rpc_auth { /* per-flavor data */ }; +/* rpc_auth au_flags */ +#define RPCAUTH_AUTH_DATATOUCH 0x00000002 + struct rpc_auth_create_args { rpc_authflavor_t pseudoflavor; const char *target_name; diff --git a/include/linux/sunrpc/gss_api.h b/include/linux/sunrpc/gss_api.h index 1f911cc..68ec78c 100644 --- a/include/linux/sunrpc/gss_api.h +++ b/include/linux/sunrpc/gss_api.h @@ -73,6 +73,7 @@ u32 gss_delete_sec_context( rpc_authflavor_t gss_svc_to_pseudoflavor(struct gss_api_mech *, u32 qop, u32 service); u32 gss_pseudoflavor_to_service(struct gss_api_mech *, u32 pseudoflavor); +bool gss_pseudoflavor_to_datatouch(struct gss_api_mech *, u32 pseudoflavor); char *gss_service_to_auth_domain_name(struct gss_api_mech *, u32 service); struct pf_desc { @@ -81,6 +82,7 @@ struct pf_desc { u32 service; char *name; char *auth_domain_name; + bool datatouch; }; /* Different mechanisms (e.g., krb5 or spkm3) may implement gss-api, and diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c index e64ae93..bca3537 100644 --- a/net/sunrpc/auth_gss/auth_gss.c +++ b/net/sunrpc/auth_gss/auth_gss.c @@ -1017,6 +1017,8 @@ gss_create_new(struct rpc_auth_create_args *args, struct rpc_clnt *clnt) auth->au_rslack = GSS_VERF_SLACK >> 2; auth->au_ops = &authgss_ops; auth->au_flavor = flavor; + if (gss_pseudoflavor_to_datatouch(gss_auth->mech, flavor)) + auth->au_flags |= RPCAUTH_AUTH_DATATOUCH; atomic_set(&auth->au_count, 1); kref_init(&gss_auth->kref); diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c index 6542749..6059583 100644 --- a/net/sunrpc/auth_gss/gss_krb5_mech.c +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c @@ -745,12 +745,14 @@ static struct pf_desc gss_kerberos_pfs[] = { .qop = GSS_C_QOP_DEFAULT, .service = RPC_GSS_SVC_INTEGRITY, .name = "krb5i", + .datatouch = true, }, [2] = { .pseudoflavor = RPC_AUTH_GSS_KRB5P, .qop = GSS_C_QOP_DEFAULT, .service = RPC_GSS_SVC_PRIVACY, .name = "krb5p", + .datatouch = true, }, }; diff --git a/net/sunrpc/auth_gss/gss_mech_switch.c b/net/sunrpc/auth_gss/gss_mech_switch.c index 7063d85..5fec3ab 100644 --- a/net/sunrpc/auth_gss/gss_mech_switch.c +++ b/net/sunrpc/auth_gss/gss_mech_switch.c @@ -361,6 +361,18 @@ gss_pseudoflavor_to_service(struct gss_api_mech *gm, u32 pseudoflavor) } EXPORT_SYMBOL(gss_pseudoflavor_to_service); +bool +gss_pseudoflavor_to_datatouch(struct gss_api_mech *gm, u32 pseudoflavor) +{ + int i; + + for (i = 0; i < gm->gm_pf_num; i++) { + if (gm->gm_pfs[i].pseudoflavor == pseudoflavor) + return gm->gm_pfs[i].datatouch; + } + return false; +} + char * gss_service_to_auth_domain_name(struct gss_api_mech *gm, u32 service) { diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c index dac2990..a47f170 100644 --- a/net/sunrpc/xprtrdma/rpc_rdma.c +++ b/net/sunrpc/xprtrdma/rpc_rdma.c @@ -570,6 +570,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) struct rpcrdma_req *req = rpcr_to_rdmar(rqst); enum rpcrdma_chunktype rtype, wtype; struct rpcrdma_msg *headerp; + bool ddp_allowed; ssize_t hdrlen; size_t rpclen; __be32 *iptr; @@ -586,6 +587,13 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) headerp->rm_credit = cpu_to_be32(r_xprt->rx_buf.rb_max_requests); headerp->rm_type = rdma_msg; + /* When the ULP employs a GSS flavor that guarantees integrity + * or privacy, direct data placement of individual data items + * is not allowed. + */ + ddp_allowed = !(rqst->rq_cred->cr_auth->au_flags & + RPCAUTH_AUTH_DATATOUCH); + /* * Chunks needed for results? * @@ -597,7 +605,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) */ if (rpcrdma_results_inline(r_xprt, rqst)) wtype = rpcrdma_noch; - else if (rqst->rq_rcv_buf.flags & XDRBUF_READ) + else if (ddp_allowed && rqst->rq_rcv_buf.flags & XDRBUF_READ) wtype = rpcrdma_writech; else wtype = rpcrdma_replych; @@ -620,7 +628,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) rtype = rpcrdma_noch; rpcrdma_inline_pullup(rqst); rpclen = rqst->rq_svec[0].iov_len; - } else if (rqst->rq_snd_buf.flags & XDRBUF_WRITE) { + } else if (ddp_allowed && rqst->rq_snd_buf.flags & XDRBUF_WRITE) { rtype = rpcrdma_readch; rpclen = rqst->rq_svec[0].iov_len; rpclen += rpcrdma_tail_pullup(&rqst->rq_snd_buf); -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Chuck Lever <chuck.lever@oracle.com> To: linux-rdma@vger.kernel.org, linux-nfs@vger.kernel.org Subject: [PATCH v3 22/25] xprtrdma: No direct data placement with krb5i and krb5p Date: Mon, 20 Jun 2016 12:11:35 -0400 [thread overview] Message-ID: <20160620161135.10809.55145.stgit@manet.1015granger.net> (raw) In-Reply-To: <20160620155751.10809.22262.stgit@manet.1015granger.net> Direct data placement is not allowed when using flavors that guarantee integrity or privacy. When such security flavors are in effect, don't allow the use of Read and Write chunks for moving individual data items. All messages larger than the inline threshold are sent via Long Call or Long Reply. On my systems (CX-3 Pro on FDR), for small I/O operations, the use of Long messages adds only around 5 usecs of latency in each direction. Note that when integrity or encryption is used, the host CPU touches every byte in these messages. Even if it could be used, data movement offload doesn't buy much in this case. Signed-off-by: Chuck Lever <chuck.lever@oracle.com> --- include/linux/sunrpc/auth.h | 3 +++ include/linux/sunrpc/gss_api.h | 2 ++ net/sunrpc/auth_gss/auth_gss.c | 2 ++ net/sunrpc/auth_gss/gss_krb5_mech.c | 2 ++ net/sunrpc/auth_gss/gss_mech_switch.c | 12 ++++++++++++ net/sunrpc/xprtrdma/rpc_rdma.c | 12 ++++++++++-- 6 files changed, 31 insertions(+), 2 deletions(-) diff --git a/include/linux/sunrpc/auth.h b/include/linux/sunrpc/auth.h index 8997915..3a40287 100644 --- a/include/linux/sunrpc/auth.h +++ b/include/linux/sunrpc/auth.h @@ -107,6 +107,9 @@ struct rpc_auth { /* per-flavor data */ }; +/* rpc_auth au_flags */ +#define RPCAUTH_AUTH_DATATOUCH 0x00000002 + struct rpc_auth_create_args { rpc_authflavor_t pseudoflavor; const char *target_name; diff --git a/include/linux/sunrpc/gss_api.h b/include/linux/sunrpc/gss_api.h index 1f911cc..68ec78c 100644 --- a/include/linux/sunrpc/gss_api.h +++ b/include/linux/sunrpc/gss_api.h @@ -73,6 +73,7 @@ u32 gss_delete_sec_context( rpc_authflavor_t gss_svc_to_pseudoflavor(struct gss_api_mech *, u32 qop, u32 service); u32 gss_pseudoflavor_to_service(struct gss_api_mech *, u32 pseudoflavor); +bool gss_pseudoflavor_to_datatouch(struct gss_api_mech *, u32 pseudoflavor); char *gss_service_to_auth_domain_name(struct gss_api_mech *, u32 service); struct pf_desc { @@ -81,6 +82,7 @@ struct pf_desc { u32 service; char *name; char *auth_domain_name; + bool datatouch; }; /* Different mechanisms (e.g., krb5 or spkm3) may implement gss-api, and diff --git a/net/sunrpc/auth_gss/auth_gss.c b/net/sunrpc/auth_gss/auth_gss.c index e64ae93..bca3537 100644 --- a/net/sunrpc/auth_gss/auth_gss.c +++ b/net/sunrpc/auth_gss/auth_gss.c @@ -1017,6 +1017,8 @@ gss_create_new(struct rpc_auth_create_args *args, struct rpc_clnt *clnt) auth->au_rslack = GSS_VERF_SLACK >> 2; auth->au_ops = &authgss_ops; auth->au_flavor = flavor; + if (gss_pseudoflavor_to_datatouch(gss_auth->mech, flavor)) + auth->au_flags |= RPCAUTH_AUTH_DATATOUCH; atomic_set(&auth->au_count, 1); kref_init(&gss_auth->kref); diff --git a/net/sunrpc/auth_gss/gss_krb5_mech.c b/net/sunrpc/auth_gss/gss_krb5_mech.c index 6542749..6059583 100644 --- a/net/sunrpc/auth_gss/gss_krb5_mech.c +++ b/net/sunrpc/auth_gss/gss_krb5_mech.c @@ -745,12 +745,14 @@ static struct pf_desc gss_kerberos_pfs[] = { .qop = GSS_C_QOP_DEFAULT, .service = RPC_GSS_SVC_INTEGRITY, .name = "krb5i", + .datatouch = true, }, [2] = { .pseudoflavor = RPC_AUTH_GSS_KRB5P, .qop = GSS_C_QOP_DEFAULT, .service = RPC_GSS_SVC_PRIVACY, .name = "krb5p", + .datatouch = true, }, }; diff --git a/net/sunrpc/auth_gss/gss_mech_switch.c b/net/sunrpc/auth_gss/gss_mech_switch.c index 7063d85..5fec3ab 100644 --- a/net/sunrpc/auth_gss/gss_mech_switch.c +++ b/net/sunrpc/auth_gss/gss_mech_switch.c @@ -361,6 +361,18 @@ gss_pseudoflavor_to_service(struct gss_api_mech *gm, u32 pseudoflavor) } EXPORT_SYMBOL(gss_pseudoflavor_to_service); +bool +gss_pseudoflavor_to_datatouch(struct gss_api_mech *gm, u32 pseudoflavor) +{ + int i; + + for (i = 0; i < gm->gm_pf_num; i++) { + if (gm->gm_pfs[i].pseudoflavor == pseudoflavor) + return gm->gm_pfs[i].datatouch; + } + return false; +} + char * gss_service_to_auth_domain_name(struct gss_api_mech *gm, u32 service) { diff --git a/net/sunrpc/xprtrdma/rpc_rdma.c b/net/sunrpc/xprtrdma/rpc_rdma.c index dac2990..a47f170 100644 --- a/net/sunrpc/xprtrdma/rpc_rdma.c +++ b/net/sunrpc/xprtrdma/rpc_rdma.c @@ -570,6 +570,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) struct rpcrdma_req *req = rpcr_to_rdmar(rqst); enum rpcrdma_chunktype rtype, wtype; struct rpcrdma_msg *headerp; + bool ddp_allowed; ssize_t hdrlen; size_t rpclen; __be32 *iptr; @@ -586,6 +587,13 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) headerp->rm_credit = cpu_to_be32(r_xprt->rx_buf.rb_max_requests); headerp->rm_type = rdma_msg; + /* When the ULP employs a GSS flavor that guarantees integrity + * or privacy, direct data placement of individual data items + * is not allowed. + */ + ddp_allowed = !(rqst->rq_cred->cr_auth->au_flags & + RPCAUTH_AUTH_DATATOUCH); + /* * Chunks needed for results? * @@ -597,7 +605,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) */ if (rpcrdma_results_inline(r_xprt, rqst)) wtype = rpcrdma_noch; - else if (rqst->rq_rcv_buf.flags & XDRBUF_READ) + else if (ddp_allowed && rqst->rq_rcv_buf.flags & XDRBUF_READ) wtype = rpcrdma_writech; else wtype = rpcrdma_replych; @@ -620,7 +628,7 @@ rpcrdma_marshal_req(struct rpc_rqst *rqst) rtype = rpcrdma_noch; rpcrdma_inline_pullup(rqst); rpclen = rqst->rq_svec[0].iov_len; - } else if (rqst->rq_snd_buf.flags & XDRBUF_WRITE) { + } else if (ddp_allowed && rqst->rq_snd_buf.flags & XDRBUF_WRITE) { rtype = rpcrdma_readch; rpclen = rqst->rq_svec[0].iov_len; rpclen += rpcrdma_tail_pullup(&rqst->rq_snd_buf);
next prev parent reply other threads:[~2016-06-20 16:11 UTC|newest] Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-06-20 16:08 [PATCH v3 00/25] NFS/RDMA client patches proposed for v4.8 Chuck Lever 2016-06-20 16:08 ` Chuck Lever [not found] ` <20160620155751.10809.22262.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org> 2016-06-20 16:08 ` [PATCH v3 01/25] xprtrdma: Remove FMRs from the unmap list after unmapping Chuck Lever 2016-06-20 16:08 ` Chuck Lever [not found] ` <20160620160843.10809.96379.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org> 2016-06-27 17:47 ` Anna Schumaker 2016-06-27 17:47 ` Anna Schumaker [not found] ` <bf577252-3786-9ee8-be3b-036922eb0507-ZwjVKphTwtPQT0dZR+AlfA@public.gmane.org> 2016-06-28 20:53 ` Chuck Lever 2016-06-28 20:53 ` Chuck Lever 2016-06-20 16:08 ` [PATCH v3 02/25] xprtrdma: Create common scatterlist fields in rpcrdma_mw Chuck Lever 2016-06-20 16:08 ` Chuck Lever 2016-06-20 16:08 ` [PATCH v3 03/25] xprtrdma: Move init and release helpers Chuck Lever 2016-06-20 16:08 ` Chuck Lever 2016-06-20 16:09 ` [PATCH v3 04/25] xprtrdma: Rename fields in rpcrdma_fmr Chuck Lever 2016-06-20 16:09 ` Chuck Lever 2016-06-20 16:09 ` [PATCH v3 05/25] xprtrdma: Use scatterlist for DMA mapping and unmapping under FMR Chuck Lever 2016-06-20 16:09 ` Chuck Lever 2016-06-20 16:09 ` [PATCH v3 06/25] xprtrdma: Refactor MR recovery work queues Chuck Lever 2016-06-20 16:09 ` Chuck Lever 2016-06-20 16:09 ` [PATCH v3 07/25] xprtrdma: Do not leak an MW during a DMA map failure Chuck Lever 2016-06-20 16:09 ` Chuck Lever 2016-06-20 16:09 ` [PATCH v3 08/25] xprtrdma: Remove ALLPHYSICAL memory registration mode Chuck Lever 2016-06-20 16:09 ` Chuck Lever 2016-06-20 16:09 ` [PATCH v3 09/25] xprtrdma: Remove rpcrdma_map_one() and friends Chuck Lever 2016-06-20 16:09 ` Chuck Lever 2016-06-20 16:09 ` [PATCH v3 10/25] xprtrdma: Clean up device capability detection Chuck Lever 2016-06-20 16:09 ` Chuck Lever 2016-06-20 16:10 ` [PATCH v3 11/25] xprtrdma: Reply buffer exhaustion can be catastrophic Chuck Lever 2016-06-20 16:10 ` Chuck Lever 2016-06-20 16:10 ` [PATCH v3 12/25] xprtrdma: Honor ->send_request API contract Chuck Lever 2016-06-20 16:10 ` Chuck Lever 2016-06-20 16:10 ` [PATCH v3 13/25] xprtrdma: Chunk list encoders must not return zero Chuck Lever 2016-06-20 16:10 ` Chuck Lever 2016-06-20 16:10 ` [PATCH v3 14/25] xprtrdma: Allocate MRs on demand Chuck Lever 2016-06-20 16:10 ` Chuck Lever 2016-06-20 16:10 ` [PATCH v3 15/25] xprtrdma: Release orphaned MRs immediately Chuck Lever 2016-06-20 16:10 ` Chuck Lever 2016-06-20 16:10 ` [PATCH v3 16/25] xprtrdma: Place registered MWs on a per-req list Chuck Lever 2016-06-20 16:10 ` Chuck Lever 2016-06-20 16:10 ` [PATCH v3 17/25] xprtrdma: Chunk list encoders no longer share one rl_segments array Chuck Lever 2016-06-20 16:10 ` Chuck Lever 2016-06-20 16:11 ` [PATCH v3 18/25] xprtrdma: rpcrdma_inline_fixup() overruns the receive page list Chuck Lever 2016-06-20 16:11 ` Chuck Lever 2016-06-20 16:11 ` [PATCH v3 19/25] xprtrdma: Do not update {head, tail}.iov_len in rpcrdma_inline_fixup() Chuck Lever 2016-06-20 16:11 ` Chuck Lever 2016-06-20 16:11 ` [PATCH v3 20/25] xprtrdma: Update only specific fields in private receive buffer Chuck Lever 2016-06-20 16:11 ` Chuck Lever 2016-06-20 16:11 ` [PATCH v3 21/25] xprtrdma: Clean up fixup_copy_count accounting Chuck Lever 2016-06-20 16:11 ` Chuck Lever 2016-06-20 16:11 ` Chuck Lever [this message] 2016-06-20 16:11 ` [PATCH v3 22/25] xprtrdma: No direct data placement with krb5i and krb5p Chuck Lever 2016-06-20 16:11 ` [PATCH v3 23/25] svc: Avoid garbage replies when pc_func() returns rpc_drop_reply Chuck Lever 2016-06-20 16:11 ` Chuck Lever 2016-06-20 16:11 ` [PATCH v3 24/25] NFS: Don't drop CB requests with invalid principals Chuck Lever 2016-06-20 16:11 ` Chuck Lever 2016-06-20 16:12 ` [PATCH v3 25/25] IB/mlx4: Workaround for mlx4_alloc_priv_pages() array allocator Chuck Lever 2016-06-20 16:12 ` Chuck Lever [not found] ` <20160620161200.10809.45762.stgit-FYjufvaPoItvLzlybtyyYzGyq/o6K9yX@public.gmane.org> 2016-06-21 5:52 ` Or Gerlitz 2016-06-21 5:52 ` Or Gerlitz [not found] ` <CAJ3xEMiS+arM2pYkZKSPe8zHZX_OidngCjVmPXpSjhNNf5_q2A-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-06-22 13:29 ` Sagi Grimberg 2016-06-22 13:29 ` Sagi Grimberg [not found] ` <576A92BA.3020703-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org> 2016-06-22 13:47 ` Or Gerlitz 2016-06-22 13:47 ` Or Gerlitz [not found] ` <CAJ3xEMiWTME0B6rKQKeCZfxK+s5p-mXcKCdThryRz+zU8V7g3g-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-06-22 14:02 ` Sagi Grimberg 2016-06-22 14:02 ` Sagi Grimberg 2016-06-22 11:56 ` Sagi Grimberg 2016-06-22 11:56 ` Sagi Grimberg 2016-06-22 14:04 ` Sagi Grimberg 2016-06-22 14:04 ` Sagi Grimberg [not found] ` <576A9AE6.4070500-NQWnxTmZq1alnMjI0IkVqw@public.gmane.org> 2016-06-22 14:09 ` Leon Romanovsky 2016-06-22 14:09 ` Leon Romanovsky 2016-06-22 14:47 ` Chuck Lever 2016-06-22 14:47 ` Chuck Lever [not found] ` <A9F49204-8E84-4B58-BAA4-5B4B360FD22F-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> 2016-06-22 15:50 ` Leon Romanovsky 2016-06-22 15:50 ` Leon Romanovsky [not found] ` <20160622155003.GI9762-2ukJVAZIZ/Y@public.gmane.org> 2016-06-22 16:20 ` Christoph Hellwig 2016-06-22 16:20 ` Christoph Hellwig 2016-06-20 18:53 ` [PATCH v3 00/25] NFS/RDMA client patches proposed for v4.8 Steve Wise 2016-06-20 18:53 ` Steve Wise 2016-06-20 19:07 ` Chuck Lever 2016-06-20 19:07 ` 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=20160620161135.10809.55145.stgit@manet.1015granger.net \ --to=chuck.lever-qhclzuegtsvqt0dzr+alfa@public.gmane.org \ --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \ --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.