From mboxrd@z Thu Jan 1 00:00:00 1970 Subject: Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE From: Benjamin Herrenschmidt In-Reply-To: References: <1085369393.15315.28.camel@gaston> <1085371988.15281.38.camel@gaston> <1085373839.14969.42.camel@gaston> <20040525034326.GT29378@dualathlon.random> <20040525114437.GC29154@parcelfarce.linux.theplanet.co.uk> <20040525153501.GA19465@foobazco.org> <20040525102547.35207879.davem@redhat.com> <20040525105442.2ebdc355.davem@redhat.com> <1085521251.24948.127.camel@gaston> Content-Type: text/plain Message-Id: <1085522735.14969.130.camel@gaston> Mime-Version: 1.0 Date: Wed, 26 May 2004 08:05:36 +1000 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Linus Torvalds Cc: "David S. Miller" , wesolows@foobazco.org, willy@debian.org, Andrea Arcangeli , Andrew Morton , Linux Kernel list , mingo@elte.hu, bcrl@kvack.org, linux-mm@kvack.org, Linux Arch list List-ID: On Wed, 2004-05-26 at 07:54, Linus Torvalds wrote: > On Wed, 26 May 2004, Benjamin Herrenschmidt wrote: > > > > Well, just setting one of those 2 bits doesn't require a hash table > > invalidate as long as nothing else changes. > > Ok. And nothing ever writes to the SW page tables outside the page table > lock, right? So on ppc64, we could just do > > #define ptep_update_dirty_accessed(ptep, entry, dirty) \ > *(ptep) = (entry) > > and be done with it. No? > > I'm not going to do it without a big ack from you. No. The hash fault path will update the PTE dirty/accessed on a hash miss exception without holding the page table lock (acts a bit like a HW TLB as far as linux is concerned). That's why it needs to be atomic. Ben. -- 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: aart@kvack.org