LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* PG_reserved bug
@ 2003-11-26 10:09 Amir Hermelin
  2003-11-26 10:17 ` William Lee Irwin III
  0 siblings, 1 reply; 6+ messages in thread
From: Amir Hermelin @ 2003-11-26 10:09 UTC (permalink / raw)
  To: linux-kernel

Hi,
I've found a bug in the 2.4.20 kernel (might have appeared before), that if
the PG_reserved flag is set on a page, its reference count will be
incremented but won't be decremented.  This is due to the wrong order of
lazy if tests in __free_pages().

I have two questions:
1.  How do I report it?  I found no maintainer for MM in MAINTAINERS
2.  I'm writing a module that gets pages (via __get_free_pages) and holds
them throughout its lifetime.  Where must I check if this page can be taken
from under me, without using the reserved bit?  In other words, if I want to
make sure the behavior is the same with or without the reserved bit, what
must I maintain?

Thanks,
Amir.



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

* Re: PG_reserved bug
  2003-11-26 10:09 PG_reserved bug Amir Hermelin
@ 2003-11-26 10:17 ` William Lee Irwin III
  2003-11-26 12:45   ` Amir Hermelin
  0 siblings, 1 reply; 6+ messages in thread
From: William Lee Irwin III @ 2003-11-26 10:17 UTC (permalink / raw)
  To: Amir Hermelin; +Cc: linux-kernel

On Wed, Nov 26, 2003 at 12:09:58PM +0200, Amir Hermelin wrote:
> Hi,
> I've found a bug in the 2.4.20 kernel (might have appeared before), that if
> the PG_reserved flag is set on a page, its reference count will be
> incremented but won't be decremented.  This is due to the wrong order of
> lazy if tests in __free_pages().
> I have two questions:
> 1.  How do I report it?  I found no maintainer for MM in MAINTAINERS
> 2.  I'm writing a module that gets pages (via __get_free_pages) and holds
> them throughout its lifetime.  Where must I check if this page can be taken
> from under me, without using the reserved bit?  In other words, if I want to
> make sure the behavior is the same with or without the reserved bit, what
> must I maintain?

Reserved pages are excepted from normal reference counting rules. The
allocators of reserved pages are expected to clear reference counts
themselves before returning them to the system (if they ever do).


-- wli

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

* RE: PG_reserved bug
  2003-11-26 10:17 ` William Lee Irwin III
@ 2003-11-26 12:45   ` Amir Hermelin
  2003-11-26 12:50     ` William Lee Irwin III
  0 siblings, 1 reply; 6+ messages in thread
From: Amir Hermelin @ 2003-11-26 12:45 UTC (permalink / raw)
  To: 'William Lee Irwin III'; +Cc: linux-kernel

Ok, fair enough.  According to what you say, this behavior won't change in
2.6.  So, I'm still left with my second question: since I do access the
pages from several places in my module, and I want to use the refcount field
of the struct page (and not have to wrap the pages in another structure) so
I know when my page is no longer referenced, how can I make sure it's 'safe'
to not use the reserved bit?

Amir.


-----Original Message-----
From: William Lee Irwin III [mailto:wli@holomorphy.com] 
Sent: Wednesday, November 26, 2003 12:18 PM
To: Amir Hermelin
Cc: linux-kernel@vger.kernel.org
Subject: Re: PG_reserved bug


On Wed, Nov 26, 2003 at 12:09:58PM +0200, Amir Hermelin wrote:
> Hi,
> I've found a bug in the 2.4.20 kernel (might have appeared before), 
> that if the PG_reserved flag is set on a page, its reference count 
> will be incremented but won't be decremented.  This is due to the 
> wrong order of lazy if tests in __free_pages(). I have two questions:
> 1.  How do I report it?  I found no maintainer for MM in MAINTAINERS
> 2.  I'm writing a module that gets pages (via __get_free_pages) and holds
> them throughout its lifetime.  Where must I check if this page can be
taken
> from under me, without using the reserved bit?  In other words, if I want
to
> make sure the behavior is the same with or without the reserved bit, what
> must I maintain?

Reserved pages are excepted from normal reference counting rules. The
allocators of reserved pages are expected to clear reference counts
themselves before returning them to the system (if they ever do).


-- wli



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

* Re: PG_reserved bug
  2003-11-26 12:45   ` Amir Hermelin
@ 2003-11-26 12:50     ` William Lee Irwin III
  2003-11-26 13:07       ` Amir Hermelin
  0 siblings, 1 reply; 6+ messages in thread
From: William Lee Irwin III @ 2003-11-26 12:50 UTC (permalink / raw)
  To: Amir Hermelin; +Cc: linux-kernel

On Wed, Nov 26, 2003 at 02:45:06PM +0200, Amir Hermelin wrote:
> Ok, fair enough.  According to what you say, this behavior won't change in
> 2.6.  So, I'm still left with my second question: since I do access the
> pages from several places in my module, and I want to use the refcount field
> of the struct page (and not have to wrap the pages in another structure) so
> I know when my page is no longer referenced, how can I make sure it's 'safe'
> to not use the reserved bit?

It looks like you'll have to wrap the pages in another structure.
The refcounts for reserved pages are effectively meaningless.


-- wli

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

* RE: PG_reserved bug
  2003-11-26 12:50     ` William Lee Irwin III
@ 2003-11-26 13:07       ` Amir Hermelin
  2003-11-26 13:09         ` William Lee Irwin III
  0 siblings, 1 reply; 6+ messages in thread
From: Amir Hermelin @ 2003-11-26 13:07 UTC (permalink / raw)
  To: 'William Lee Irwin III'; +Cc: linux-kernel

Can't I just not use the reserved bit (therefore effectively use the
refcount), and keep the minimal count at 1 or 2?  Will that have the same
effect as setting the reserved bit?

Amir.

-----Original Message-----
From: linux-kernel-owner@vger.kernel.org
[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of William Lee Irwin
III
Sent: Wednesday, November 26, 2003 2:50 PM
To: Amir Hermelin
Cc: linux-kernel@vger.kernel.org
Subject: Re: PG_reserved bug


On Wed, Nov 26, 2003 at 02:45:06PM +0200, Amir Hermelin wrote:
> Ok, fair enough.  According to what you say, this behavior won't 
> change in 2.6.  So, I'm still left with my second question: since I do 
> access the pages from several places in my module, and I want to use 
> the refcount field of the struct page (and not have to wrap the pages 
> in another structure) so I know when my page is no longer referenced, 
> how can I make sure it's 'safe' to not use the reserved bit?

It looks like you'll have to wrap the pages in another structure. The
refcounts for reserved pages are effectively meaningless.


-- wli
-
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/



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

* Re: PG_reserved bug
  2003-11-26 13:07       ` Amir Hermelin
@ 2003-11-26 13:09         ` William Lee Irwin III
  0 siblings, 0 replies; 6+ messages in thread
From: William Lee Irwin III @ 2003-11-26 13:09 UTC (permalink / raw)
  To: Amir Hermelin; +Cc: linux-kernel

On Wed, Nov 26, 2003 at 03:07:13PM +0200, Amir Hermelin wrote:
> Can't I just not use the reserved bit (therefore effectively use the
> refcount), and keep the minimal count at 1 or 2?  Will that have the same
> effect as setting the reserved bit?

You can do that, yes. There are certain disadvantages to doing so, e.g.
poor interactions with higher-order allocations.


-- wli

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

end of thread, other threads:[~2003-11-26 13:09 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-11-26 10:09 PG_reserved bug Amir Hermelin
2003-11-26 10:17 ` William Lee Irwin III
2003-11-26 12:45   ` Amir Hermelin
2003-11-26 12:50     ` William Lee Irwin III
2003-11-26 13:07       ` Amir Hermelin
2003-11-26 13:09         ` William Lee Irwin III

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).