possible bug in page allocation mechanism

possible bug in page allocation mechanism

[Tim Cullen]

There appears to be a inconsistenancy with reference
counts on pages allocated with alloc_pages when order
is greater than zero. In buffered_rmqueue when order
!= 0 then __rmqueue is called. This returns a page
pointer that is really a pointer to the first page in
a group of pages. Subsequently prep_new_page is called
on the first page of the group but not on any others.
This results in the first page having a reference
count of 1 while all other pages in the allocation
have a reference count of 0. I would think that all
pages in the same allocation should all have the same
reference count at the end of the allocation.

I've looked at this in the 2.6.20, 2.6.19.1, and the
2.6.17.7 kernels. They contain the same code in this
area.

I don't have a solution to offer, but I wanted to
bring it to the attention of those who have more
knowledge about the workings of the page allocation
system.

tim



 
____________________________________________________________________________________
Don't pick lemons.
See all the new 2007 cars at Yahoo! Autos.
http://autos.yahoo.com/new_cars.html 

Re: possible bug in page allocation mechanism

[Andrew Morton]

On Thu, 15 Feb 2007 14:11:42 -0800 (PST) Tim Cullen <timcullen2001@yahoo.com> wrote:

> There appears to be a inconsistenancy with reference
> counts on pages allocated with alloc_pages when order
> is greater than zero. In buffered_rmqueue when order
> != 0 then __rmqueue is called. This returns a page
> pointer that is really a pointer to the first page in
> a group of pages. Subsequently prep_new_page is called
> on the first page of the group but not on any others.
> This results in the first page having a reference
> count of 1 while all other pages in the allocation
> have a reference count of 0. I would think that all
> pages in the same allocation should all have the same
> reference count at the end of the allocation.
> 
> I've looked at this in the 2.6.20, 2.6.19.1, and the
> 2.6.17.7 kernels. They contain the same code in this
> area.
> 

That's as-designed.  All page refcount manipulations on a higher-order page
are supposed to be against the head pageframe.

Also, we have the compound page logic in there to force code which tries to
manipulate the refcount of a tail page to be redirected to the head page.