From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Mason Subject: Re: Why doesn't zap_pte_range() call page_mkwrite() Date: Fri, 24 Apr 2009 08:59:49 -0400 Message-ID: <1240577989.32585.1.camel@think.oraclecorp.com> References: <1240510668.11148.40.camel@heimdal.trondhjem.org> <1240519320.5602.9.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 7bit Cc: trond.myklebust@fys.uio.no, npiggin@suse.de, linux-nfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org To: Miklos Szeredi Return-path: Received: from rcsinet13.oracle.com ([148.87.113.125]:24387 "EHLO rgminet13.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752612AbZDXNCi (ORCPT ); Fri, 24 Apr 2009 09:02:38 -0400 In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, 2009-04-24 at 09:33 +0200, Miklos Szeredi wrote: > On Fri, 24 Apr 2009, Miklos Szeredi wrote: > > Hmm, I guess this is a bit nasty: the VM promises filesystems that > > ->page_mkwrite() will be called when the page is dirtied through a > > mapping, _almost_ all of the time. Except when munmap happens to race > > with clear_page_dirty_for_io(). > > > > I don't have any ideas how this could be fixed, CC-ing linux-mm... > > On second thought, we could possibly just ignore the dirty bit in that > case. Trying to write to a mapping _during_ munmap() will have pretty > undefined results, I don't think any sane application out there should > rely on the results of this. > > But how knows, the world is a weird place... It does happen in practice, btrfs has fallback code that triggers the page_mkwrite when it finds a dirty page that wasn't dirtied with help from the FS. I'd love to get rid of the fallback ;) -chris