LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* possible bug in page allocation mechanism
@ 2007-02-15 22:11 Tim Cullen
  2007-02-16  5:53 ` Andrew Morton
  0 siblings, 1 reply; 2+ messages in thread
From: Tim Cullen @ 2007-02-15 22:11 UTC (permalink / raw)
  To: linux-kernel; +Cc: timcullen2001

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 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: possible bug in page allocation mechanism
  2007-02-15 22:11 possible bug in page allocation mechanism Tim Cullen
@ 2007-02-16  5:53 ` Andrew Morton
  0 siblings, 0 replies; 2+ messages in thread
From: Andrew Morton @ 2007-02-16  5:53 UTC (permalink / raw)
  To: Tim Cullen; +Cc: linux-kernel

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.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2007-02-16  5:53 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-15 22:11 possible bug in page allocation mechanism Tim Cullen
2007-02-16  5:53 ` Andrew Morton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).