From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Date: Tue, 17 Oct 2017 08:46:47 +0200 Message-ID: <20171017064647.GA15437@lst.de> References: <20171012142319.GA11254@lst.de> <20171013065716.GB26461@lst.de> <20171013163822.GA17411@obsidianresearch.com> <20171013173145.GA18702@obsidianresearch.com> <20171016072644.GB28270@lst.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: Sender: linux-api-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org To: Dan Williams Cc: Christoph Hellwig , Jason Gunthorpe , "linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw@public.gmane.org" , linux-xfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , Linux API , Dave Chinner , "J. Bruce Fields" , Linux MM , Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel , Jeff Layton , Linus Torvalds , Andrew Morton List-Id: linux-api@vger.kernel.org On Mon, Oct 16, 2017 at 12:44:31PM -0700, Dan Williams wrote: > > While I agree with the need for a per-MR notification mechanism, one > > thing we lose by walking away from MAP_DIRECT is a way for a > > hypervisor to coordinate pass through of a DAX mapping to an RDMA > > device in a guest. That will remain a case where we will still need to > > use device-dax. I'm fine if that's the answer, but just want to be > > clear about all the places we need to protect a DAX mapping against > > RDMA from a non-ODP device. > > For this specific issue perhaps we promote FL_LAYOUT as a lease-type > that can be set by fcntl(). I don't think it is a good userspace interface, mostly because it is about things that don't matter for userspace (block mappings). It makes sense as a kernel interface for callers that want to pin down a memory long-term, but for userspace the fact that the block mapping changes doesn't matter - it matters that their long term pin is broken by something. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from newverein.lst.de (verein.lst.de [213.95.11.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id BCF0D202E5CDD for ; Mon, 16 Oct 2017 23:43:13 -0700 (PDT) Date: Tue, 17 Oct 2017 08:46:47 +0200 From: Christoph Hellwig Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Message-ID: <20171017064647.GA15437@lst.de> References: <20171012142319.GA11254@lst.de> <20171013065716.GB26461@lst.de> <20171013163822.GA17411@obsidianresearch.com> <20171013173145.GA18702@obsidianresearch.com> <20171016072644.GB28270@lst.de> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: Dan Williams Cc: linux-xfs@vger.kernel.org, Jan Kara , Andy Lutomirski , Arnd Bergmann , "linux-nvdimm@lists.01.org" , Linux API , "Darrick J. Wong" , Dave Chinner , Andrew Morton , Jason Gunthorpe , Linux MM , Al Viro , "J. Bruce Fields" , Jeff Layton , linux-fsdevel , Linus Torvalds , Christoph Hellwig List-ID: On Mon, Oct 16, 2017 at 12:44:31PM -0700, Dan Williams wrote: > > While I agree with the need for a per-MR notification mechanism, one > > thing we lose by walking away from MAP_DIRECT is a way for a > > hypervisor to coordinate pass through of a DAX mapping to an RDMA > > device in a guest. That will remain a case where we will still need to > > use device-dax. I'm fine if that's the answer, but just want to be > > clear about all the places we need to protect a DAX mapping against > > RDMA from a non-ODP device. > > For this specific issue perhaps we promote FL_LAYOUT as a lease-type > that can be set by fcntl(). I don't think it is a good userspace interface, mostly because it is about things that don't matter for userspace (block mappings). It makes sense as a kernel interface for callers that want to pin down a memory long-term, but for userspace the fact that the block mapping changes doesn't matter - it matters that their long term pin is broken by something. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from verein.lst.de ([213.95.11.211]:58428 "EHLO newverein.lst.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932526AbdJQGqt (ORCPT ); Tue, 17 Oct 2017 02:46:49 -0400 Date: Tue, 17 Oct 2017 08:46:47 +0200 From: Christoph Hellwig Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Message-ID: <20171017064647.GA15437@lst.de> References: <20171012142319.GA11254@lst.de> <20171013065716.GB26461@lst.de> <20171013163822.GA17411@obsidianresearch.com> <20171013173145.GA18702@obsidianresearch.com> <20171016072644.GB28270@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-xfs-owner@vger.kernel.org List-ID: List-Id: xfs To: Dan Williams Cc: Christoph Hellwig , Jason Gunthorpe , "linux-nvdimm@lists.01.org" , linux-xfs@vger.kernel.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , Linux API , Dave Chinner , "J. Bruce Fields" , Linux MM , Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel , Jeff Layton , Linus Torvalds , Andrew Morton On Mon, Oct 16, 2017 at 12:44:31PM -0700, Dan Williams wrote: > > While I agree with the need for a per-MR notification mechanism, one > > thing we lose by walking away from MAP_DIRECT is a way for a > > hypervisor to coordinate pass through of a DAX mapping to an RDMA > > device in a guest. That will remain a case where we will still need to > > use device-dax. I'm fine if that's the answer, but just want to be > > clear about all the places we need to protect a DAX mapping against > > RDMA from a non-ODP device. > > For this specific issue perhaps we promote FL_LAYOUT as a lease-type > that can be set by fcntl(). I don't think it is a good userspace interface, mostly because it is about things that don't matter for userspace (block mappings). It makes sense as a kernel interface for callers that want to pin down a memory long-term, but for userspace the fact that the block mapping changes doesn't matter - it matters that their long term pin is broken by something. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 17 Oct 2017 08:46:47 +0200 From: Christoph Hellwig To: Dan Williams Cc: Christoph Hellwig , Jason Gunthorpe , "linux-nvdimm@lists.01.org" , linux-xfs@vger.kernel.org, Jan Kara , Arnd Bergmann , "Darrick J. Wong" , Linux API , Dave Chinner , "J. Bruce Fields" , Linux MM , Jeff Moyer , Al Viro , Andy Lutomirski , Ross Zwisler , linux-fsdevel , Jeff Layton , Linus Torvalds , Andrew Morton Subject: Re: [PATCH v9 0/6] MAP_DIRECT for DAX userspace flush Message-ID: <20171017064647.GA15437@lst.de> References: <20171012142319.GA11254@lst.de> <20171013065716.GB26461@lst.de> <20171013163822.GA17411@obsidianresearch.com> <20171013173145.GA18702@obsidianresearch.com> <20171016072644.GB28270@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: On Mon, Oct 16, 2017 at 12:44:31PM -0700, Dan Williams wrote: > > While I agree with the need for a per-MR notification mechanism, one > > thing we lose by walking away from MAP_DIRECT is a way for a > > hypervisor to coordinate pass through of a DAX mapping to an RDMA > > device in a guest. That will remain a case where we will still need to > > use device-dax. I'm fine if that's the answer, but just want to be > > clear about all the places we need to protect a DAX mapping against > > RDMA from a non-ODP device. > > For this specific issue perhaps we promote FL_LAYOUT as a lease-type > that can be set by fcntl(). I don't think it is a good userspace interface, mostly because it is about things that don't matter for userspace (block mappings). It makes sense as a kernel interface for callers that want to pin down a memory long-term, but for userspace the fact that the block mapping changes doesn't matter - it matters that their long term pin is broken by something. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org