Messages in this thread |  | | Date | Wed, 21 Aug 2002 10:41:48 -0700 | From | Andrew Morton <> | Subject | Re: Race in pagevec code |
| |
Christian Ehrhardt wrote: > > ... > Both processors succeeded in bringing the page_count to zero, > i.e. both processors will add the page to their own > pages_to_free_list.
This is why __pagevec_release() has the refcount check inside the lock. If someone else grabbed a ref to the page (also inside the lock) via the LRU, __pagevec_release doesn't free it.
So the rule could be stated as: the page gets freed when there are no references to it, presence on the LRU counts as a reference, serialisation is via pagemap_lru_lock.
> .. > > I don't have a fix but I think the only real solution is to > increment the page count if a page is on a lru list. After all > this is a reference to the page.
One would think so, but that doesn't really change anything.
I agree the locking and reffing in there is really nasty. It doesn't help that I put four, repeat four bugs in the 20-line __page_cache_release(). __pagevec_release() is, I think, OK.
It would be much simpler to grab the lock each time page_cache_release() is executed, but our performance targets for 2.5 preclude that.
The page->pte.chain != NULL problems predate the locking changes. We haven't found that one yet. - 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/
|  |