Re: [PATCH]: fix the bug of __free_pages() of mm/page_alloc.c

[Russell King <rmk+lkml@arm.linux.org.uk>]

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