Messages in this thread | | | Subject | Re: [PATCH] ppc64: Fix possible race with set_pte on a present PTE | From | Benjamin Herrenschmidt <> | Date | Tue, 25 May 2004 14:40:25 +1000 |
| |
On Tue, 2004-05-25 at 14:37, Andrea Arcangeli wrote: > 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.
Isn't this the work of pte_clear ? It's quite important to be very careful about such PTE manipulations on ppc & ppc64 or we can wreck everything by losting the hash state bits in there.
> 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. -- Benjamin Herrenschmidt <benh@kernel.crashing.org>
- 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/
| |