Messages in this thread | | | 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 |
| |
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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |