lkml.org 
[lkml]   [2002]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: MM patches against 2.5.31
Date
On Wednesday 28 August 2002 23:03, Andrew Morton wrote:
> Daniel Phillips wrote:
> >
> > Going right back to basics, what do you suppose is wrong with the 2.4
> > strategy of always doing the lru removal in free_pages_ok?
>
> That's equivalent to what we have at present, which is:
>
> if (put_page_testzero(page)) {
> /* window here */
> lru_cache_del(page);
> __free_pages_ok(page, 0);
> }
>
> versus:
>
> spin_lock(lru lock);
> page = list_entry(lru, ...);
> if (page_count(page) == 0)
> continue;
> /* window here */
> page_cache_get(page);
> page_cache_release(page); /* double-free */

Indeed it is. In 2.4.19 we have:

(vmscan.c: shrink_cache) (page_alloc.c: __free_pages)

365 if (unlikely(!page_count(page)))
366 continue;
444 if (!PageReserved(page) && put_page_testzero(page))
[many twisty paths, all different]
511 /* effectively free the page here */
512 page_cache_release(page);
445 __free_pages_ok(page, order);
[free it again just to make sure]

So there's no question that the race is lurking in 2.4. I noticed several
more paths besides the one above that look suspicious as well. The bottom
line is, 2.4 needs a fix along the lines of my suggestion or Christian's,
something that can actually be proved.

It's a wonder that this problem manifests so rarely in practice.

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

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