[lkml]   [2000]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread

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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.103 / U:0.184 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site