Re: [RFC][patch 0/2] mm: remove PageReserved

[Hugh Dickins <hugh@veritas.com>]

On Tue, 9 Aug 2005, Russell King wrote:
> On Tue, Aug 09, 2005 at 02:59:53PM +1000, Nick Piggin wrote:
> > That would work for swsusp, but there are other users that want to
> > know if a struct page is valid ram (eg. ioremap), so in that case
> > swsusp would not be able to mess with the flag.
> 
> The usage of "valid ram" here is confusing - that's not what PageReserved
> is all about.  It's about valid RAM which is managed by method other
> than the usual page counting.

You're right (though I imagine might sometimes be holes rather than RAM).

PageReserved is about those pages which are managed by PageReserved.
But quite what it means is unclear, one of the reasons to eliminate it.
(Why is kernel text PageReserved?)

> Non-reserved RAM is also valid RAM, but
> is managed by the kernel in the usual way.
> 
> The former is available for remap_pfn_range and ioremap, the latter is
> not.

And the caller of remap_pfn_range (and occasionally ioremap?) uses
SetPageReserved to move pages from the latter to the former category,
so that they will work successfully on it.

Seems very silly to me.  A little key we give the caller,
so the caller can reassure us "I know what I'm doing".

I think Nick is treating the "use" of PageReserved in ioremap much too
reverentially.  Fine to leave its removal from there to a later stage,
but why shouldn't that also be removed?

With or without PageReserved, driver writers should be careful to apply
ioremap to the areas they intend.  And when they do get it wrong (setting
a window on the wrong range of RAM), the new VM_RESERVED handling makes
sure that at least those wrong pages won't be freed when unmapped.

Hugh
--
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>