From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) (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 CA07421F322B0 for ; Tue, 26 Sep 2017 14:03:34 -0700 (PDT) Date: Tue, 26 Sep 2017 15:06:45 -0600 From: Ross Zwisler Subject: Re: [PATCH 6/7] mm, fs: introduce file_operations->post_mmap() Message-ID: <20170926210645.GA7798@linux.intel.com> References: <20170925231404.32723-1-ross.zwisler@linux.intel.com> <20170925231404.32723-7-ross.zwisler@linux.intel.com> <20170926185751.GB31146@linux.intel.com> 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: Jeff Layton , Jan Kara , Andrew Morton , "Darrick J. Wong" , "linux-nvdimm@lists.01.org" , Dave Chinner , "linux-kernel@vger.kernel.org" , "J. Bruce Fields" , Linux MM , linux-fsdevel , linux-xfs@vger.kernel.org, Christoph Hellwig List-ID: On Tue, Sep 26, 2017 at 12:19:21PM -0700, Dan Williams wrote: > On Tue, Sep 26, 2017 at 11:57 AM, Ross Zwisler <> > > This decision can only be made (in this > > proposed scheme) *after* the inode->i_mapping->i_mmap tree has been > > populated, which means we need another call into the filesystem after this > > insertion has happened. > > I get that, but it seems over-engineered and something that can also > be safely cleaned up after the fact by the code path that is disabling > DAX. I don't think you can safely clean it up after the fact because some thread might have already called ->mmap() to set up the vma->vm_flags for their new mapping, but they haven't added it to inode->i_mapping->i_mmap. The inode->i_mapping->i_mmap tree is the only way (that I know of at least) that the filesystem has any idea about about the mapping. This is the method by which we would try and clean up mapping flags, if we were to do so, and it's the only way that the filesystem can know whether or not mappings exist. The only way that I could think of to make this safely work is to have the insertion into the inode->i_mapping->i_mmap tree be our sync point. After that the filesystem and the mapping code can communicate on the state of DAX, but before that I think it's basically indeterminate. _______________________________________________ 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 mga06.intel.com ([134.134.136.31]:47425 "EHLO mga06.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754506AbdIZVGs (ORCPT ); Tue, 26 Sep 2017 17:06:48 -0400 Date: Tue, 26 Sep 2017 15:06:45 -0600 From: Ross Zwisler Subject: Re: [PATCH 6/7] mm, fs: introduce file_operations->post_mmap() Message-ID: <20170926210645.GA7798@linux.intel.com> References: <20170925231404.32723-1-ross.zwisler@linux.intel.com> <20170925231404.32723-7-ross.zwisler@linux.intel.com> <20170926185751.GB31146@linux.intel.com> 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: Ross Zwisler , Andrew Morton , "linux-kernel@vger.kernel.org" , "Darrick J. Wong" , "J. Bruce Fields" , Christoph Hellwig , Dave Chinner , Jan Kara , Jeff Layton , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , linux-xfs@vger.kernel.org On Tue, Sep 26, 2017 at 12:19:21PM -0700, Dan Williams wrote: > On Tue, Sep 26, 2017 at 11:57 AM, Ross Zwisler <> > > This decision can only be made (in this > > proposed scheme) *after* the inode->i_mapping->i_mmap tree has been > > populated, which means we need another call into the filesystem after this > > insertion has happened. > > I get that, but it seems over-engineered and something that can also > be safely cleaned up after the fact by the code path that is disabling > DAX. I don't think you can safely clean it up after the fact because some thread might have already called ->mmap() to set up the vma->vm_flags for their new mapping, but they haven't added it to inode->i_mapping->i_mmap. The inode->i_mapping->i_mmap tree is the only way (that I know of at least) that the filesystem has any idea about about the mapping. This is the method by which we would try and clean up mapping flags, if we were to do so, and it's the only way that the filesystem can know whether or not mappings exist. The only way that I could think of to make this safely work is to have the insertion into the inode->i_mapping->i_mmap tree be our sync point. After that the filesystem and the mapping code can communicate on the state of DAX, but before that I think it's basically indeterminate. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Tue, 26 Sep 2017 15:06:45 -0600 From: Ross Zwisler To: Dan Williams Cc: Ross Zwisler , Andrew Morton , "linux-kernel@vger.kernel.org" , "Darrick J. Wong" , "J. Bruce Fields" , Christoph Hellwig , Dave Chinner , Jan Kara , Jeff Layton , linux-fsdevel , Linux MM , "linux-nvdimm@lists.01.org" , linux-xfs@vger.kernel.org Subject: Re: [PATCH 6/7] mm, fs: introduce file_operations->post_mmap() Message-ID: <20170926210645.GA7798@linux.intel.com> References: <20170925231404.32723-1-ross.zwisler@linux.intel.com> <20170925231404.32723-7-ross.zwisler@linux.intel.com> <20170926185751.GB31146@linux.intel.com> 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 Tue, Sep 26, 2017 at 12:19:21PM -0700, Dan Williams wrote: > On Tue, Sep 26, 2017 at 11:57 AM, Ross Zwisler <> > > This decision can only be made (in this > > proposed scheme) *after* the inode->i_mapping->i_mmap tree has been > > populated, which means we need another call into the filesystem after this > > insertion has happened. > > I get that, but it seems over-engineered and something that can also > be safely cleaned up after the fact by the code path that is disabling > DAX. I don't think you can safely clean it up after the fact because some thread might have already called ->mmap() to set up the vma->vm_flags for their new mapping, but they haven't added it to inode->i_mapping->i_mmap. The inode->i_mapping->i_mmap tree is the only way (that I know of at least) that the filesystem has any idea about about the mapping. This is the method by which we would try and clean up mapping flags, if we were to do so, and it's the only way that the filesystem can know whether or not mappings exist. The only way that I could think of to make this safely work is to have the insertion into the inode->i_mapping->i_mmap tree be our sync point. After that the filesystem and the mapping code can communicate on the state of DAX, but before that I think it's basically indeterminate. -- 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