From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S265157AbUEYWQz (ORCPT ); Tue, 25 May 2004 18:16:55 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S265144AbUEYWNq (ORCPT ); Tue, 25 May 2004 18:13:46 -0400 Received: from fw.osdl.org ([65.172.181.6]:48269 "EHLO mail.osdl.org") by vger.kernel.org with ESMTP id S265183AbUEYWJq (ORCPT ); Tue, 25 May 2004 18:09:46 -0400 Date: Tue, 25 May 2004 15:09:33 -0700 (PDT) From: Linus Torvalds To: Benjamin Herrenschmidt 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 Subject: Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE In-Reply-To: <1085521251.24948.127.camel@gaston> Message-ID: 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> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org 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. I'm starting to doubt this, because: > We do dirty by mapping r/o in the hash table, and accessed on hash > faults (our clear_young triggers a flush). So just setting those bits > in the linux PTE without touching the hash table is fine, we'll just > possibly take an extra fault on the next write or access, but that > might not be much slower than going to the hash update the permissions > directly. But if we don't update the hash tables, how will the TLB entry _ever_ say that the page is writable? So we won't take just _one_ extra fault on the next write, we'll _keep_ taking them, since the hash tables will continue to claim that the page is read-only, even if the linux sw page tables say it is writable. So I think the code needs to invalidate the hash after having updated the pte. No? Linus