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

From: Daniel Phillips (phillips@arcor.de)
Date: Mon Sep 02 2002 - 14:35:06 EST


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;
 
-
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/



This archive was generated by hypermail 2b29 : Sat Sep 07 2002 - 22:00:16 EST