See it. The scenario im thinking about is:
CPU1 CPU2
pick page from lru
Lock it
get_page
try_to_release_buffers fails
UnlockPage
/* Window here */
Pick page form lru
page_cache_get
Lock it
actually free the buffers
UnlockPage
page_cache_release
doesn't remove the page from
the lru because CPU 1 holds
a reference
put_page dropps last reference
but doenn't remove the page from
the lru because it is put_page
and not page_cache release.
---> Page gets freed while it is still on the lru. If the lru cache
holds a reference that's a non issue.
CPU1 is the path in shrink_cache.
I admit that I don't have a real path that does what CPU2 does in
this scenario but doing what CPU2 does should be perfectly legal.
> Besides that, we have a promise that the page still has buffers, worth
Not after UnlockPage.
> another count, and the page will never be freed here. That's fragile
> though, and this particular piece of code can no doubt be considerably
> simplified, while improving robustness and efficiency at the same time.
> But that goes beyond the scope of this patch.
Well yes ;-) There's funny things going on like accessing a page
after page_cache_release...
regards Christian
-- THAT'S ALL FOLKS! - 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/