lkml.org 
[lkml]   [2011]   [May]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRE: [PATCH] ARM: sparsemem: allow pfn_valid to be overridden when using SPARSEMEM
On Wednesday, May 18, 2011 9:04 AM, Will Deacon wrote:
>
> In commit eb33575c ("[ARM] Double check memmap is actually valid with a
> memmap has unexpected holes V2"), a new function, memmap_valid_within,
> was introduced to mmzone.h so that holes in the memmap which pass
> pfn_valid in SPARSEMEM configurations can be detected and avoided.
>
> The fix to this problem checks that the pfn <-> page linkages are
> correct by calculating the page for the pfn and then checking that
> page_to_pfn on that page returns the original pfn. Unfortunately, in
> SPARSEMEM configurations, this results in reading from the page flags to
> determine the correct section. Since the memmap here has been freed,
> junk is read from memory and the check is no longer robust.
>
> In the best case, reading from /proc/pagetypeinfo will give you the
> wrong answer. In the worst case, you get SEGVs, Kernel OOPses and hung
> CPUs.
>
> This patch allows architectures to provide their own pfn_valid function
> instead of using the default implementation used by sparsemem. The
> architecture-specific version is aware of the memmap state and will
> return false when passed a pfn for a freed page within a valid section.
>
> Cc: Russell King <linux@arm.linux.org.uk>
> Cc: Mel Gorman <mgorman@suse.de>
> Acked-by: Catalin Marinas <catalin.marinas@arm.com>
> Signed-off-by: Will Deacon <will.deacon@arm.com>

I tested this on an EP93xx based system which uses ARCH_HAS_HOLES_MEMORYMODEL.
The EP9307A has 64MB of memory that appears as two 32MB blocks at addresses
0xc0000000 and 0xc4000000. Currently the EP93xx uses a Flat Memory model and
the hole used to cause a Kernel OOPs before commit e80d6a24 ("[ARM] Skip memory
holes in FLATMEM when reading /proc/pagetypeinfo"), which is where I think this
all started.

Without your patch I get this when reading /proc/pagetypeinfo:

# cat /proc/pagetypeinfo
Page block order: 10
Pages per block: 1024

Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10
Node 0, zone Normal, type Unmovable 3 4 3 0 2 2 4 5 2 2 3
Node 0, zone Normal, type Reclaimable 2 0 0 0 1 0 0 1 0 1 0
Node 0, zone Normal, type Movable 0 3 4 1 1 1 0 1 0 2 4
Node 0, zone Normal, type Reserve 1 1 1 2 0 0 0 0 0 0 0
Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0

Number of blocks type Unmovable Reclaimable Movable Reserve Isolate
Node 0, zone Normal 8 1 6 1 0

After your patch I get this:

# cat /proc/pagetypeinfo
Page block order: 10
Pages per block: 1024

Free pages count per migrate type at order 0 1 2 3 4 5 6 7 8 9 10
Node 0, zone Normal, type Unmovable 1 0 2 0 1 3 4 3 3 2 3
Node 0, zone Normal, type Reclaimable 0 1 0 0 1 0 0 1 0 1 0
Node 0, zone Normal, type Movable 1 1 1 1 0 0 1 1 0 2 4
Node 0, zone Normal, type Reserve 1 1 1 2 0 0 0 0 0 0 0
Node 0, zone Normal, type Isolate 0 0 0 0 0 0 0 0 0 0 0

Number of blocks type Unmovable Reclaimable Movable Reserve Isolate
Node 0, zone Normal 8 1 6 1 0

I'm not sure what the output "should" be, but the patch does not seem to
cause any issues. So feel free to add:

Tested-by: H Hartley Sweeten <hsweeten@visionengravers.com>


\
 
 \ /
  Last update: 2011-05-18 20:55    [W:0.221 / U:0.100 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site