From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Mon, 9 Oct 2006 23:27:14 -0700 From: Andrew Morton Subject: Re: [patch] mm: bug in set_page_dirty_buffers Message-Id: <20061009232714.b52f678d.akpm@osdl.org> In-Reply-To: <20061010061958.GA25500@wotan.suse.de> References: <20061010035851.GK15822@wotan.suse.de> <20061009211404.ad112128.akpm@osdl.org> <20061010042144.GM15822@wotan.suse.de> <20061009213806.b158ea82.akpm@osdl.org> <20061010044745.GA24600@wotan.suse.de> <20061009220127.c4721d2d.akpm@osdl.org> <20061010052248.GB24600@wotan.suse.de> <20061009222905.ddd270a6.akpm@osdl.org> <20061010054832.GC24600@wotan.suse.de> <20061009230832.7245814e.akpm@osdl.org> <20061010061958.GA25500@wotan.suse.de> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Linus Torvalds , Peter Zijlstra , Linux Memory Management List , Greg KH List-ID: On Tue, 10 Oct 2006 08:19:58 +0200 Nick Piggin wrote: > On Mon, Oct 09, 2006 at 11:08:32PM -0700, Andrew Morton wrote: > > On Tue, 10 Oct 2006 07:48:33 +0200 > > Nick Piggin wrote: > > > > > > Am I missing something? > > > > Well it's a matter of reviewing all codepaths in the kernel which > > manipulate internal page state and see if they're racy against their > > ->set_page_dirty(). All because of zap_pte_range(). > > And page_remove_rmap. page_remove_rmap()'s call to set_page_dirty(). Same thing. > > The page lock protects internal page state. It'd be better to fix > > zap_pte_range(). > > > > How about we trylock the page and if that fails, back out and drop locks > > and lock the page then dirty it and then resume the zap? Negligible > > overhead, would be nice and simple apart from that i_mmap_lock thing. > > What about page_remove_rmap? > > I don't see why. This has been the documented behaviour for ages, and > it seems to be made fairly clear in comments around mm/ and filesystems. > Considering the only nontrivial ->spds are those which set PageChecked > as well, I don't see why there is much to audit (other than fs/buffer.c). Which approach is a good design? > Not that I think it would be a bad idea for filesystems writers to audit > carefully against truncate, Good luck with that. It needs to be done for them. > because that's been screwed up in the VM for > so long... What has? Please be specific. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org