![]() | |||||||||||||
Messages in this thread |
David Gibson <david@gibson.dropbear.id.au> wrote: > > Andrew, please apply. > > The code of put_page() is misleading, in that it appears to have code > handling PageCompound pages (i.e. hugepages). However it won't > actually handle them correctly - __page_cache_release() will not work > properly on a compound. Instead, hugepages should be and are released > with huge_page_release() from mm/hugetlb.c. This patch removes the > broken PageCompound path from put_page(), replacing it with a > BUG_ON(). This also removes the initialization of page[1].mapping > from compoound pages, which was only ever used in this broken code > path. We could certainly remove the test for a null destructor in there and require that compound pages have a destructor installed. But the main reason why that code is in there is for transparently handling direct-io into hugepage regions. That code does perform put_page against 4k pageframes within the huge page and it does follow the pointer to the head page. With your patch applied get_user_pages() and bio_release_pages() will manipulate the refcounts of the inner 4k pages rather than the head pages and things will explode. We could change follow_hugetlb_page() to always take a ref against the head page and we could teach bio_release_pages() to perform appropriate pfn masking to locate the head page, and perform similar tricks for futexes-in-large-pages. But with the code as-is the refcounting works transparently. If it's "broken" I wanna know why. - 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:02 [from the cache] ©2003-2008 | |||||||||||||