
From: Hugh Dickins <hugh@veritas.com>

A small change to the tests for "Bad page state", to avoid one class of the
page_remove_rmap BUG reports, giving more information while letting the
system continue: check page_mapcount (_mapcount != -1) rather than
page_mapped (_mapcount >= 0).

And how does _mapcount go bad?  In the case under study, it looks sure now
that an overheating(?) Pentium III sometimes gets confused by a pair of
instructions in the no-buddy-bitmap __free_pages_bulk, and clears the
PG_private bit from the _mapcount field while buddying around - changing
PG_private value changes the bit cleared from _mapcount.  Bad page state
mapcount:-4096 would have tracked this down much sooner, and will be
recognizable if other cpus show the same aberrant reaction to 2.6.11.

The page_remove_rmap BUG does need to be replaced by more permissive and
informative handling, but I'm not yet ready to to finalize such a patch.

Please admit Colin Harrison to the Order of the Iridescent Penguin, for his
tireless testing.

Signed-off-by: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
---

 25-akpm/mm/page_alloc.c |    4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -puN mm/page_alloc.c~bad-page-state-mapcount mm/page_alloc.c
--- 25/mm/page_alloc.c~bad-page-state-mapcount	2005-03-07 20:41:24.000000000 -0800
+++ 25-akpm/mm/page_alloc.c	2005-03-07 20:41:24.000000000 -0800
@@ -306,7 +306,7 @@ static inline void __free_pages_bulk (st
 
 static inline void free_pages_check(const char *function, struct page *page)
 {
-	if (	page_mapped(page) ||
+	if (	page_mapcount(page) ||
 		page->mapping != NULL ||
 		page_count(page) != 0 ||
 		(page->flags & (
@@ -433,7 +433,7 @@ void set_page_refs(struct page *page, in
  */
 static void prep_new_page(struct page *page, int order)
 {
-	if (page->mapping || page_mapped(page) ||
+	if (page->mapping || page_mapcount(page) ||
 	    (page->flags & (
 			1 << PG_private	|
 			1 << PG_locked	|
_
