On Tue, 2005-08-09 at 15:50 +0100, Hugh Dickins wrote:

On Tue, 9 Aug 2005, Benjamin Herrenschmidt wrote:

quoted

quoted

But you don't mind if they are refcounted, do you?
Just so long as they start out from 1 so never get freed.

Well, a refcounting bug would let them be freed and kaboom ... That's
why a "PG_not_your_ram_dammit" bit would be useful. It could at least
BUG_ON when refcount reaches 0 :)

Okay, great, let's give every struct page two refcounts,
so if one of them goes wrong, the other one will save us.

You are abusing here :)

 - We already have a refcount
 - We have a field where putting a flag isn't that much of a problem
 - It can be difficult to get page refcounting right when dealing with
   such things, really.

In that case, we basically have an _easy_ way to trigger a useful BUG()
in the page free path when it's a page that should never be returned to
the pool.

Since the "PG_not_in_ram" or whatever we call it flag might be used by
swsusp or others, I suppose it could be useful.

However, I agree that if the end result is to have drivers just change
"PG_reserved" to "PG_not_in_ram" and still be bogus, then we might just
go all the way & drop the flag completely, only relying on the VMA
flags.

Ben.


--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>