linux-kernel - RE: [PATCH] ARM: sparsemem: allow pfn_valid to be overridden when using SPARSEMEM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 18 May 2011 13:53:08 -0500
From:	H Hartley Sweeten <hartleys@...ionengravers.com>
To:	Will Deacon <will.deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
CC:	Russell King <linux@....linux.org.uk>, Mel Gorman <mgorman@...e.de>
Subject: RE: [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@....linux.org.uk>
> Cc: Mel Gorman <mgorman@...e.de>
> Acked-by: Catalin Marinas <catalin.marinas@....com>
> Signed-off-by: Will Deacon <will.deacon@....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@...ionengravers.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/