I've done a bit of analysis:
cmpxchg fail fault mm=c3945b20 vma=c304ad84 addr=402cb000 write=2048
ptep=c2af5b2c pmd=c2bc5008 entry=886c0f7 new=886c077 current=886c077
Note the Dirty bit is set on entry and not new where it probably should
be...
ptep_cmpxchg(mm, address, pte, entry, new_entry)
This will compare "current"(886c077) with "entry"(886c0f7) which are not
equal and the whole thing therefore correctly fails leading to the loop.
The following patch (against -mm) cleared the problem up but I'm not
sure how correct it is:
Index: linux-2.6.12/mm/memory.c
===================================================================
--- linux-2.6.12.orig/mm/memory.c 2005-08-08 23:03:45.000000000 +0100
+++ linux-2.6.12/mm/memory.c 2005-08-08 23:04:02.000000000 +0100
@@ -2046,7 +2046,7 @@
return do_wp_page(mm, vma, address, pte, pmd, entry);
#endif
}
- entry = pte_mkdirty(entry);
+ new_entry = pte_mkdirty(entry);
}
/*
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
