From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: hole-punch vs fault Date: Mon, 2 Dec 2013 09:33:18 +0100 Message-ID: <20131202083318.GA2188@quack.suse.cz> References: <20131127134831.GI24288@parisc-linux.org> <20131127221932.GA27330@quack.suse.cz> <20131128023343.GJ24288@parisc-linux.org> <20131128044454.GL24288@parisc-linux.org> <20131128221246.GQ8803@dastard> <20131129131154.GA11106@parisc-linux.org> <20131201215221.GW10988@dastard> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Matthew Wilcox , Jan Kara , linux-fsdevel@vger.kernel.org To: Dave Chinner Return-path: Received: from cantor2.suse.de ([195.135.220.15]:57973 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752627Ab3LBIdX (ORCPT ); Mon, 2 Dec 2013 03:33:23 -0500 Content-Disposition: inline In-Reply-To: <20131201215221.GW10988@dastard> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon 02-12-13 08:52:21, Dave Chinner wrote: > > I'm solving two cases here, one is holepunch vs fault for regular > > files. The other is truncate vs fault for XIP files, which is > > probably a little less rare. I think the same mechanism can be > > used when a filesystem is doing a defragment or otherwise moving > > blocks around on an XIP block device. > > Well, you kind of raised that as a secondary issue in passing, not > that it was the problem you actually need to solve. > > > Look, I'm not attached to the i_damage solution, > > but I do need something to protect against truncate vs fault on XIP. > > Fixing holepunch vs fault too just felt like the right thing to do. > > So, your real problem is that ext2-xip has a truncate vs fault race > because of a lack of a page lock to serialise page faults against > truncate. In fact, it appears to bypass the page cache completely > for both reads and writes (writes go directly to block device > memory), so it would seem that all the assumptions we've made about > serialisation on page locks throughout every filesystem are not > valid for XIP? Yeah, agreed. > Indeed, XIP could make use of the structures we already > have in the struct inode/address space to behave more like a normal > filesystem. We already use the mapping tree to store > per-page information that is used to serialise truncate vs page > faults, so why not make XIP do exactly the same thing? I believe that grabbing mmap_sem for writing during truncate (in case of ext2 around xip_truncate_page() & truncate_setsize() calls should do the trick. But I need to verify with lockdep that it doesn't introduce new locking problems. Honza -- Jan Kara SUSE Labs, CR