Messages in this thread | | | Date | Fri, 23 Apr 2004 01:34:37 -0700 | From | Andrew Morton <> | Subject | Re: put_page() tries to handle hugepages but fails |
| |
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/
| |