On Thu, Jan 20, 2005 at 09:34:17PM +0800, zhan rongkai wrote:
> [PATCH]: fix the bug of __free_pages() of mm/page_alloc.c
> =========================================================
>
> The buddy allocator's __free_pages() function seems to be buggy.
>
> The following codes are from kernel 2.6.10:
>
> fastcall void __free_pages(struct page *page, unsigned int order)
> {
> if (!PageReserved(page) && put_page_testzero(page)) {
> if (order == 0)
> free_hot_page(page);
> else
> __free_pages_ok(page, order);
> }
> }
>
> As you know, before truely freeing all pages, this function calls
> put_page_testzero(page) to
> drop the refcount of the pages.
>
> But, in fact the macro put_page_testzero(page) **only** drops **one**
> page's refcount.
> Therefore, if (order > 0), the refcounts of (page+1) ..
> (page+(1<<order)-1) are unchanged!
> This will cause __free_pages_ok() to dump stack, because it finds some
> pages' page_count()
> are not zero!
When you allocate a page with order > 0, the first 0-order page has a
refcount of 1, and the remaining 0-order pages have a refcount of 0.
If you're triggering this check, I suspect you're fiddling about with
the individual pages (using get_page on them individually?) which is
a no-no.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
