Messages in this thread |  | | From | Daniel Phillips <> | Subject | Re: MM patches against 2.5.31 | Date | Thu, 29 Aug 2002 00:04:46 +0200 |
| |
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/
|  |