lkml.org 
[lkml]   [2005]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectRe: 2.6.13-rc3-mm3
On Mon, 1 Aug 2005, Richard Purdie wrote:
> That number rapidly increases and so it looks like something is failing
> and looping...

Maybe we better restore the pte flags changes the way they were if
CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works
then we need two different handle_pte_fault functions to get rid of the
macro mess:

Index: linux-2.6.13-rc4-mm1/mm/memory.c
===================================================================
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-01 12:59:49.000000000 -0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c 2005-08-01 15:08:31.000000000 -0700
@@ -2094,6 +2094,7 @@
entry = pte_mkdirty(entry);
}

+#ifdef CONFIG_ATOMIC_TABLE_OPS
/*
* If the cmpxchg fails then another processor may have done
* the changes for us. If not then another fault will bring
@@ -2106,6 +2107,11 @@
} else {
inc_page_state(cmpxchg_fail_flag_update);
}
+#else
+ ptep_set_access_flags(vma, address, pte, entry, write_access);
+ update_mmu_cache(vma, address, entry);
+ lazy_mmu_prot_update(entry);
+#endif

pte_unmap(pte);
page_table_atomic_stop(mm);
Index: linux-2.6.13-rc4-mm1/mm/memory.o
===================================================================
Binary files linux-2.6.13-rc4-mm1.orig/mm/memory.o 2005-08-01 15:03:10.000000000 -0700 and linux-2.6.13-rc4-mm1/mm/memory.o 2005-08-01 15:09:50.000000000 -0700 differ
-
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/
\
 
 \ /
  Last update: 2005-08-02 00:26    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site