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:17:41 +1000 |
| |
> and similarly on most other architectures it should be quite easy to do > the equivalent. You can always do it with a simple compare-and-exchange > loop, something any SMP-capable architecture should have. > > Of course, arguably we can actually optimize this by "knowing" that it is > safe to set the dirty bit, so then we don't even need an atomic operation, > we just need one atomic write. So we only actually need the atomic op for > the accessed bit case, and if we make the write-case be totally separate..
Looks good ! That gives us a guarantee that set_pte is never ever called on a present PTE (thus letting set_pte be non-atomic) and we can safely BUG_ON(pte_present(*ptep)) in it, right ?
Note that having different set_dirty and set_accessed may be useful for some archs, thouh I agree a single atomic operation is enough on ppc too, I also want to make sure nobody ever gets the idea of using that for anything but those 2 bits... Well, that's a matter of taste, go for what you prefer.
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)
> Anybody willing to write up a patch for a few architectures? Is there any > architecture out there that would have a problem with this? > > Linus > - > 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/ -- 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/
| |