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 <matthew.r.wilcox@xxxxxxxxx> > > 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
