RE: [PATCH] ARM: sparsemem: allow pfn_valid to be overridden whenusing SPARSEMEM
From: H Hartley Sweeten
Date: Wed May 18 2011 - 14:53:25 EST
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@xxxxxxxxxxxxxxxx>
> Cc: Mel Gorman <mgorman@xxxxxxx>
> Acked-by: Catalin Marinas <catalin.marinas@xxxxxxx>
> Signed-off-by: Will Deacon <will.deacon@xxxxxxx>
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@xxxxxxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/