From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Wilcox Subject: Re: hole-punch vs fault Date: Mon, 2 Dec 2013 08:58:25 -0700 Message-ID: <20131202155825.GA11028@parisc-linux.org> 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> <20131202083318.GA2188@quack.suse.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Dave Chinner , linux-fsdevel@vger.kernel.org To: Jan Kara Return-path: Received: from palinux.external.hp.com ([192.25.206.14]:41553 "EHLO mail.parisc-linux.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751972Ab3LBP61 (ORCPT ); Mon, 2 Dec 2013 10:58:27 -0500 Content-Disposition: inline In-Reply-To: <20131202083318.GA2188@quack.suse.cz> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mon, Dec 02, 2013 at 09:33:18AM +0100, Jan Kara wrote: > > 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. Umm ... mmap_sem for write? On each of the tasks that have a file mmaped? I know we have double_down that orders by memory address, but I don't think we have an N_down_write(). -- Matthew Wilcox Intel Open Source Technology Centre "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."