From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com ([192.55.52.120]:62868 "EHLO mga04.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932157AbcBAVZT (ORCPT ); Mon, 1 Feb 2016 16:25:19 -0500 Date: Mon, 1 Feb 2016 14:25:11 -0700 From: Ross Zwisler To: Matthew Wilcox Cc: Ross Zwisler , Matthew Wilcox , Jan Kara , Dave Chinner , Ross Zwisler , "linux-fsdevel@vger.kernel.org" Subject: Re: [PATCH 0/2] Fix dax races between page faults RFC only Message-ID: <20160201212511.GA30560@linux.intel.com> References: <1453867708-3999-1-git-send-email-matthew.r.wilcox@intel.com> <20160127061830.GS2948@linux.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160127061830.GS2948@linux.intel.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Jan 27, 2016 at 01:18:30AM -0500, Matthew Wilcox wrote: > On Tue, Jan 26, 2016 at 10:50:59PM -0700, Ross Zwisler wrote: > > On Tuesday, January 26, 2016, Matthew Wilcox > > wrote: > > > If I understand the current state of the code correctly, truncate can't > > > race with the fault handler, so the re-checks we do of i_size are now > > > dead code, which can be deleted. right? > > > > Yep, I think so. I think we might be able to delete all the i_mmap locking > > in dax.c as well, now that the isolation from truncate all happens at the > > filesystem level. > > No; we need to preserve the lock against truncate back down into the > MM code. Consider the cow_page case; if truncate comes in after we drop > the filesystem lock and before the COWed page is inserted into the page > table, truncate won't see the page in order to remove it. And truncate > is supposed to remove COWs as well as the underlying file. Yep, agreed. > I'm not sure what purpose it serves in dax_insert_mapping though. Nor > the PMD fault handler. Yep, AFAIK these two can be removed since they are now synchronized with truncate via the filesystem level locking.