Re: Race in pagevec code

[Andrew Morton <akpm@zip.com.au>]

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.