Re: 2.4.0-test8-pre1 is quite bad / how about integrating Rik's VM now?

From: Linus Torvalds (torvalds@transmeta.com)
Date: Sun Sep 03 2000 - 14:16:54 EST


On Sun, 3 Sep 2000, Rik van Riel wrote:
> > Rik.
> >
> > You're apparently completely ignoring the fact that the page
> > "already on the LRU queue" was just allocated from
> > __alloc_pages() in the backtrace you had.
>
> It wasn't. If it was allocated there, the boobytraps in
> either rmqueue() or page_reclaim() would have caught it.

What you're saying is that you're ignoring the evidence because you don't
like it and you don't understand how it happens.

The BUG() was "impossible", so you're discounting it?

I can tell you several ways it happens in.
 - modify the page after free_page(). free_page() won't see bad state,
   but alloc_page() will.
 - race: one user uses a page at the same time another user does a
   free_page(). Somebody doesn't do a proper "get_page()" or honour the
   locking. Again, this effectively results in modifying the page after
   having free'd it.

There's a bug somewhere. It seems to have the free page stuff on a page
that should have been free already.

The fact that the boobytraps don't trigger probably means that they aren't
working, and aren't catching the case we're interested in. Dont' say "that
cannot be the bug, because if it were the bug the boobytraps would have
caught it" - because you apparently have _multiple_ traces of this
happening on pages fresh out of "alloc_pages()".

NOTE! The bug may be old. I'm not necessarily blaming your code. I
couldn't see anything wrong in your patches. I'm just saying that you seem
to be in denial about the fact that the pages come from the freelist, at
least in the one trace I saw.

                Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/



This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:16 EST