Messages in this thread | | | Date | Sun, 3 Sep 2000 16:38:40 -0300 (BRST) | From | Rik van Riel <> |
| |
On Sun, 3 Sep 2000, Linus Torvalds wrote: > 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.
__alloc_pages() didn't see it either, but Christian seems to have found a possible cause for the bug (as you got by private email).
> - 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.
> 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.
This indeed seems to be the case, except that the corruption happens /after/ the page is handed over by __alloc_pages()...
(see Christian's email)
regards,
Rik -- "What you're running that piece of shit Gnome?!?!" -- Miguel de Icaza, UKUUG 2000
http://www.conectiva.com/ http://www.surriel.com/
- 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/
| |