From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 25 May 2004 06:37:29 +0200 From: Andrea Arcangeli Subject: Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE Message-ID: <20040525043729.GV29378@dualathlon.random> References: <1085369393.15315.28.camel@gaston> <1085371988.15281.38.camel@gaston> <1085373839.14969.42.camel@gaston> <20040525034326.GT29378@dualathlon.random> <1085458660.14969.106.camel@gaston> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1085458660.14969.106.camel@gaston> Sender: owner-linux-mm@kvack.org Return-Path: To: Benjamin Herrenschmidt Cc: Linus Torvalds , Andrew Morton , Linux Kernel list , Ingo Molnar , Ben LaHaise , linux-mm@kvack.org, Architectures Group List-ID: On Tue, May 25, 2004 at 02:17:41PM +1000, Benjamin Herrenschmidt wrote: > on a present PTE (thus letting set_pte be non-atomic) and we can safely > BUG_ON(pte_present(*ptep)) in it, right ? set_pte is used even to mark the pte non present, so you can forget about using BUG_ON(pte_present(*ptep)) anywhere in set_pte regardless of how we fix this race (see mm/objrmap.c:unmap_pte_page()). If you want to trap for it you should add a set_pte_present and use it at least in objrmap.c during the paging. > ppc64 version of this would look like > > static inline unsigned long ptep_set_bits(pte_t *p, unsigned long set) > { > unsigned long old, tmp; > > __asm__ __volatile__( > "1: ldarx %0,0,%3\n\ > or %1,%0,%4 \n\ > stdcx. %1,0,%3 \n\ > bne- 1b" > : "=&r" (old), "=&r" (tmp), "=m" (*p) > : "r" (p), "r" (clr), "m" (*p) > : "cc" ); > return old; > } > > ppc32 would be: > > #define ptep_set_bits(p, bits) pte_update(p, 0, bits) unless you are generating page faults if the young bit is clear, this will only slowdown compared to my simpler approch. However if some arch is using page faults to set the young bit in hardware (not in software), then slowing micro-down x86 and others might be an option to share all the common code, but we could easily avoid smp locking in x86 and alpha by threating the young-bit-page-fault archs differently too. Would be nice to hear from the ia64 folks what they're doing w.r.t. to the young bit, I think ia64 is the only one providing the young bit with an hardware page fault. -- 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