Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE

[Andrea Arcangeli <andrea@suse.de>]

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: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>