Re: Kernel BUG at page_alloc.c:91! (2.4.19)

[Daniel Phillips]

On Monday 02 September 2002 14:54, Heiko Carstens wrote:
> Hi Daniel,
> 
> >> Looks to me that this function itself has a bug: after the drop_pte 
> label
> >> it is checked if the current page has a mapping. If this is true there 
> is
> >> ...
> >Chances are, you've run into the subtle double-free race I've been 
> working
> >on for the last few days.  Would you like to try this patch as see if it
> >makes a difference?
> >http://nl.linux.org/~phillips/patches/lru.race-2.4.19
> 
> Thanks for the patch but unfortunately it doesn't change the behaviour at
> all. This BUG is still 100% reproducible by just having 1 process which
> allocates memory chunks of 256KB and after each allocation writes to each
> of the pages in order to make them dirty.

Um, no smp --> no free race anyway.  But try the following instead, to
start narrowing down the possibilities:

--- ./vmscan.c	2002-09-02 21:15:17.000000000 +0200
+++ mm/vmscan.c	2002-09-02 21:33:24.000000000 +0200
@@ -82,7 +82,7 @@
 	 */
 	if (PageSwapCache(page)) {
 		entry.val = page->index;
-		swap_duplicate(entry);
+		BUG_ON(!swap_duplicate(entry));
 set_swap_pte:
 		set_pte(page_table, swp_entry_to_pte(entry));
 drop_pte:
@@ -109,8 +109,10 @@
 	 * Basically, this just makes it possible for us to do
 	 * some real work in the future in "refill_inactive()".
 	 */
-	if (page->mapping)
+	if (page->mapping) {
+		BUG_ON( page_count(page) == 1);
 		goto drop_pte;
+	}
 	if (!PageDirty(page))
 		goto drop_pte;