On Sep 3, 2008, at 10:12 PM, Benjamin Herrenschmidt wrote:
On Wed, 2008-09-03 at 13:09 -0500, Kumar Gala wrote:
There are some minor issues with support 64-bit PTEs on a 32-bit
processor
when dealing with SMP.
* We need to order the stores in set_pte_at to make sure the flag
word
is set second.
* Change pte_clear to use pte_update so only the flag word is cleared
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
Fixed pte_clear to not break on 6xx.
Thanks :-)
static inline unsigned long long pte_update(pte_t *p,
unsigned long clr,
unsigned long set)
@@ -658,8 +656,17 @@ static inline void set_pte_at(struct mm_struct
*mm, unsigned long addr,
#if _PAGE_HASHPTE != 0
pte_update(ptep, ~_PAGE_HASHPTE, pte_val(pte) & ~_PAGE_HASHPTE);
#else
+#if defined(CONFIG_PTE_64BIT) && defined(CONFIG_SMP)
Minor nit, but there's #elif :-)
+ __asm__ __volatile__("\
+ stw%U0%X0 %2,%0\n\
+ eieio\n\
+ stw%U0%X0 %L2,%1"
+ : "=m" (*ptep), "=m" (*((unsigned char *)ptep+4))
+ : "r" (pte) : "memory");
Any reason why it has to be in assembly ? Can gcc re-order stores
around
eieio() if written in C ? I would hope not but heh ... it's gcc :-)
I'm leaving it asm. Its more explicit and easier to read in my
opinion and I don't give gcc a chance to screw us over.
I also wonder if you should first ensure that the PTE is invalid and
if not, clear it and flush the TLB page ... Or at least add a
WARN_ON(pte_valid()) in case we get that wrong ...
I believe that's an issue since kmap_atomic() will call set_pte_at and
have the valid bit set.
- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
