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: <1085377091.15281.49.camel@gaston> References: <1085369393.15315.28.camel@gaston> <1085371988.15281.38.camel@gaston> <1085373839.14969.42.camel@gaston> <1085376888.24948.45.camel@gaston> <1085377091.15281.49.camel@gaston> Content-Type: text/plain Message-Id: <1085377936.15024.55.camel@gaston> Mime-Version: 1.0 Date: Mon, 24 May 2004 15:52:17 +1000 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Linus Torvalds Cc: Andrew Morton , Linux Kernel list , Ingo Molnar , Ben LaHaise , linux-mm@kvack.org List-ID: On Mon, 2004-05-24 at 15:38, Benjamin Herrenschmidt wrote: > > Well, the original scenario triggering that from userland is, imho, so > > broken, that we may just not care losing that dirty bit ... Oh well :) > > Anyway, apply my patch. If pte is not present, this will have no effect, > > if it is, it makes sure we never leave a stale HPTE in the hash, which > > is fatal in far worse ways. > > Hrm... Or maybe I should just do in set_pte something like > > BUG_ON(pte_present(ptep)) > > That would make me sleep better ;) ... And would not work in the case you mentioned where we set it with the dirty bit set... for write protect, we have a separate function now, though. But I'm a bit paranoid with those PTE manipulations, so I think it would be better to play it the safe way and keep my original patch. 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