From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Thu, 14 Aug 2008 13:47:17 +0100 (BST) From: Hugh Dickins Subject: Re: [rfc][patch] mm: dirty page accounting race fix In-Reply-To: <1218716318.10800.209.camel@twins> Message-ID: References: <20080814094537.GA741@wotan.suse.de> <1218716318.10800.209.camel@twins> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Peter Zijlstra Cc: Nick Piggin , Linux Memory Management List , Linux Kernel Mailing List List-ID: On Thu, 14 Aug 2008, Peter Zijlstra wrote: > On Thu, 2008-08-14 at 12:55 +0100, Hugh Dickins wrote: > > > But I got a bit distracted: mprotect's change_pte_range is > > traditionally where the pte_modify operation has been split up into > > stages on some arches, that really can be restricting permissions > > and needs to tread carefully. Now I go to look there, I see its > > /* > > * Avoid taking write faults for pages we know to be > > * dirty. > > */ > > if (dirty_accountable && pte_dirty(ptent)) > > ptent = pte_mkwrite(ptent); > > > > and get rather worried: isn't that likely to be giving write permission > > to a pte in a vma we are precisely taking write permission away from? > > Exactly, we do that because the page is already dirty, therefore we do > not need to trap on write to mark it dirty - at least, that was the idea > behind this optimization. I realized that was the intended optimization, what I'd missed is that dirty_accountable can only be true there if (vma->vm_flags & VM_WRITE): that's checked in vma_wants_writenotify(), which is how dirty_accountable gets to be set. So those lines are okay, panic over, phew. Hugh -- 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