All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Cc: Wendy Cheng
	<s.wendy.cheng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
	Tom Talpey <tom-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org>,
	"linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
	<linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux NFS Mailing List
	<linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Shirley Ma <shirley.ma-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
Subject: Re: Proposal for simplifying NFS/RDMA client memory registration
Date: Sat, 1 Mar 2014 11:00:22 -0500	[thread overview]
Message-ID: <20140301110022.417eb088@tlielax.poochiereds.net> (raw)
In-Reply-To: <B83B4DA6-E9CF-4DF3-9227-5EF9B4D25F4D-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>

On Fri, 28 Feb 2014 21:59:00 -0500
Chuck Lever <chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org> wrote:

> Hi Wendy-
> 
> On Feb 28, 2014, at 5:26 PM, Wendy Cheng <s.wendy.cheng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> 
> > On Fri, Feb 28, 2014 at 2:20 PM, Wendy Cheng <s.wendy.cheng@gmail.com> wrote:
> >> ni i...On Fri, Feb 28, 2014 at 1:41 PM, Tom Talpey <tom-CLs1Zie5N5HQT0dZR+AlfA@public.gmane.org> wrote:
> >>> 
> >>> On 2/26/2014 8:44 AM, Chuck Lever wrote:
> >>>> 
> >>>> Hi-
> >>>> 
> >>>> Shirley Ma and I are reviving work on the NFS/RDMA client code base in
> >>>> the Linux kernel.  So far we've built and run functional tests to determine
> >>>> what is working and what is broken.
> >>>> 
> >>>> [snip]
> >> 
> >> 
> >>>> 
> >>>> ALLPHYSICAL - Usually fast, but not safe as it exposes client memory.
> >>>> All HCAs support this mode.
> >>> 
> >>> 
> >>> Not safe is an understatement. It exposes all of client physical
> >>> memory to the peer, for both read and write. A simple pointer error
> >>> on the server will silently corrupt the client. This mode was
> >>> intended only for testing, and in experimental deployments.
> > 
> > (sorry, resend .. previous reply bounced back due to gmail html format)
> > 
> > Please keep "ALLPHYSICAL" for now  - as our embedded system needs it.
> 
> This is just the client side.  Confirming that you still need support for the ALLPHYSICAL memory registration mode in the NFS/RDMA client.
> 
> Do you have plans to move to a mode that is less risky?  If not, can we depend on you to perform regular testing with ALLPHYSICAL as we update the client code?  Do you have any bug fixes you’d like to merge upstream?
> 

Also, given that ALLPHYSICAL isn't considered safe, we should at the
very least require some sort of explicit opt-in before allowing it to be
used. Perhaps either a Kconfig option, or maybe a runtime switch like a
module parm?

Wendy, would that be acceptable?
-- 
Jeff Layton <jlayton-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: Jeff Layton <jlayton@redhat.com>
To: Chuck Lever <chuck.lever@oracle.com>
Cc: Wendy Cheng <s.wendy.cheng@gmail.com>,
	Tom Talpey <tom@talpey.com>,
	"linux-rdma@vger.kernel.org" <linux-rdma@vger.kernel.org>,
	Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
	Shirley Ma <shirley.ma@oracle.com>
Subject: Re: Proposal for simplifying NFS/RDMA client memory registration
Date: Sat, 1 Mar 2014 11:00:22 -0500	[thread overview]
Message-ID: <20140301110022.417eb088@tlielax.poochiereds.net> (raw)
In-Reply-To: <B83B4DA6-E9CF-4DF3-9227-5EF9B4D25F4D@oracle.com>

On Fri, 28 Feb 2014 21:59:00 -0500
Chuck Lever <chuck.lever@oracle.com> wrote:

> Hi Wendy-
> 
> On Feb 28, 2014, at 5:26 PM, Wendy Cheng <s.wendy.cheng@gmail.com> wrote:
> 
> > On Fri, Feb 28, 2014 at 2:20 PM, Wendy Cheng <s.wendy.cheng@gmail.com> wrote:
> >> ni i...On Fri, Feb 28, 2014 at 1:41 PM, Tom Talpey <tom@talpey.com> wrote:
> >>> 
> >>> On 2/26/2014 8:44 AM, Chuck Lever wrote:
> >>>> 
> >>>> Hi-
> >>>> 
> >>>> Shirley Ma and I are reviving work on the NFS/RDMA client code base in
> >>>> the Linux kernel.  So far we've built and run functional tests to determine
> >>>> what is working and what is broken.
> >>>> 
> >>>> [snip]
> >> 
> >> 
> >>>> 
> >>>> ALLPHYSICAL - Usually fast, but not safe as it exposes client memory.
> >>>> All HCAs support this mode.
> >>> 
> >>> 
> >>> Not safe is an understatement. It exposes all of client physical
> >>> memory to the peer, for both read and write. A simple pointer error
> >>> on the server will silently corrupt the client. This mode was
> >>> intended only for testing, and in experimental deployments.
> > 
> > (sorry, resend .. previous reply bounced back due to gmail html format)
> > 
> > Please keep "ALLPHYSICAL" for now  - as our embedded system needs it.
> 
> This is just the client side.  Confirming that you still need support for the ALLPHYSICAL memory registration mode in the NFS/RDMA client.
> 
> Do you have plans to move to a mode that is less risky?  If not, can we depend on you to perform regular testing with ALLPHYSICAL as we update the client code?  Do you have any bug fixes you’d like to merge upstream?
> 

Also, given that ALLPHYSICAL isn't considered safe, we should at the
very least require some sort of explicit opt-in before allowing it to be
used. Perhaps either a Kconfig option, or maybe a runtime switch like a
module parm?

Wendy, would that be acceptable?
-- 
Jeff Layton <jlayton@redhat.com>

  parent reply	other threads:[~2014-03-01 16:00 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-26 16:44 Proposal for simplifying NFS/RDMA client memory registration Chuck Lever
2014-02-26 16:44 ` Chuck Lever
     [not found] ` <01C4496A-F074-4F72-9DF0-6076C05E8A1F-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-02-26 17:42   ` faibish, sorin
2014-02-26 17:42     ` faibish, sorin
2014-02-28 21:41   ` Tom Talpey
2014-02-28 21:41     ` Tom Talpey
     [not found]     ` <CABgxfbHwo13ma=-Xn+S36WwD8LVNLdw6UHztFe8EkCA_=NBenw@mail.gmail.com>
     [not found]       ` <CABgxfbHwo13ma=-Xn+S36WwD8LVNLdw6UHztFe8EkCA_=NBenw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-02-28 22:26         ` Wendy Cheng
2014-02-28 22:26           ` Wendy Cheng
     [not found]           ` <CABgxfbHg0B02c2zpYdCB4pUZZhhA4aKRuyh4Kx=NE1yAisFLLQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2014-03-01  2:59             ` Chuck Lever
2014-03-01  2:59               ` Chuck Lever
     [not found]               ` <B83B4DA6-E9CF-4DF3-9227-5EF9B4D25F4D-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-03-01 16:00                 ` Jeff Layton [this message]
2014-03-01 16:00                   ` Jeff Layton
     [not found]                   ` <20140301110022.417eb088-9yPaYZwiELC+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2014-03-01 17:14                     ` Chuck Lever
2014-03-01 17:14                       ` Chuck Lever
2014-03-01 21:29                 ` Tom Tucker
2014-03-01 21:29                   ` Tom Tucker
     [not found]                   ` <53125125.9010709-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW@public.gmane.org>
2014-03-02 22:28                     ` Chuck Lever
2014-03-02 22:28                       ` Chuck Lever
2014-03-03 17:02   ` Chuck Lever
2014-03-03 17:02     ` Chuck Lever
     [not found]     ` <E755E683-C064-4ED3-8448-C61F4E5AF16E-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org>
2014-03-03 19:07       ` Christoph Hellwig
2014-03-03 19:07         ` Christoph Hellwig
     [not found]         ` <20140303190733.GA4556-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
2014-03-03 19:54           ` faibish, sorin
2014-03-03 19:54             ` faibish, sorin
     [not found]             ` <79E85B7D-5ECC-4A63-BB07-C45A570DA53D-mb1K0bWo544@public.gmane.org>
2014-03-03 20:33               ` Wendy Cheng
2014-03-03 20:33                 ` Wendy Cheng

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=20140301110022.417eb088@tlielax.poochiereds.net \
    --to=jlayton-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=chuck.lever-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=s.wendy.cheng-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
    --cc=shirley.ma-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org \
    --cc=tom-CLs1Zie5N5HQT0dZR+AlfA@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: link
Be 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.