* maybe backport to stable: 3b3d7c4 ("mm/init: fix zone boundary creation")
[not found] <58778d9d.08301c0a.bb8d8.2c60@mx.google.com>
@ 2017-01-12 14:50 ` Arnd Bergmann
2017-01-13 10:53 ` Greg KH
2017-01-18 0:21 ` Oliver O'Halloran
0 siblings, 2 replies; 3+ messages in thread
From: Arnd Bergmann @ 2017-01-12 14:50 UTC (permalink / raw)
To: Greg KH
Cc: kernel-build-reports, kernelci. org bot, Oliver O'Halloran,
Anton Blanchard, Benjamin Herrenschmidt, Paul Mackerras,
Mel Gorman, Andrew Morton, stable
On Thursday, January 12, 2017 6:07:25 AM CET kernelci. org bot wrote:
> stable build: 199 builds: 1 failed, 198 passed, 68 warnings (v4.4.42)
>
Things are looking much better already, and I found one upstream
patch (from v4.8) that fixes more than half of the remaining MIPS and
x86 warnings on linux-4.4-stable:
> mips: gcc version 6.3.0 (GCC)
>
> allnoconfig: 1 warning
> ar7_defconfig: 2 warnings
> ath79_defconfig: 1 warning
> bcm47xx_defconfig: 1 warning
> bcm63xx_defconfig: 1 warning
> capcella_defconfig: 2 warnings
> ci20_defconfig: 1 warning
> cobalt_defconfig: 1 warning
> db1xxx_defconfig: 1 warning
> decstation_defconfig: 4 warnings
> defconfig+CONFIG_LKDTM=y: 2 warnings
> e55_defconfig: 1 warning
> fuloong2e_defconfig: 1 warning
> gpr_defconfig: 2 warnings
> ip22_defconfig: 2 warnings
> ip27_defconfig: 2 warnings
> ip32_defconfig: 1 warning
> jazz_defconfig: 1 warning
> jmr3927_defconfig: 1 warning
> lasat_defconfig: 1 warning
> lemote2f_defconfig: 2 warnings
> loongson3_defconfig: 2 warnings
> ls1b_defconfig: 1 warning
> markeins_defconfig: 1 warning
> mips_paravirt_defconfig: 1 warning
> mpc30x_defconfig: 1 warning
> msp71xx_defconfig: 2 warnings
> mtx1_defconfig: 2 warnings
> nlm_xlp_defconfig: 4 warnings
> nlm_xlr_defconfig: 3 warnings
> pistachio_defconfig: 1 warning
> pnx8335_stb225_defconfig: 1 warning
> qi_lb60_defconfig: 1 warning
> rb532_defconfig: 1 warning
> rbtx49xx_defconfig: 1 warning
> rm200_defconfig: 1 warning
> rt305x_defconfig: 4 warnings
> sead3_defconfig: 1 warning
> sead3micro_defconfig: 1 warning
> tb0219_defconfig: 1 warning
> tb0226_defconfig: 1 warning
> tb0287_defconfig: 1 warning
> tinyconfig: 1 warning
> workpad_defconfig: 1 warning
> xilfpga_defconfig: 1 warning
> xway_defconfig: 1 warning
>
> x86: gcc version 4.8.4 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
>
> tinyconfig: 1 warning
>
> Warnings summary:
>
> 41 mm/page_alloc.c:5705:34: warning: array subscript is below array bounds [-Warray-bounds]
I don't understand that patch enough to say if it is appropriate
for a backport, but it applies cleanly on v4.4 and fixes the warning.
Adding everyone who was involved so they can comment.
Arnd
8<---
>From 90cae1fe1c3540f791d5b8e025985fa5e699b2bb Mon Sep 17 00:00:00 2001
From: Oliver O'Halloran <oohall@gmail.com>
Date: Tue, 26 Jul 2016 15:22:17 -0700
Subject: [PATCH] mm/init: fix zone boundary creation
As a part of memory initialisation the architecture passes an array to
free_area_init_nodes() which specifies the max PFN of each memory zone.
This array is not necessarily monotonic (due to unused zones) so this
array is parsed to build monotonic lists of the min and max PFN for each
zone. ZONE_MOVABLE is special cased here as its limits are managed by
the mm subsystem rather than the architecture. Unfortunately, this
special casing is broken when ZONE_MOVABLE is the not the last zone in
the zone list. The core of the issue is:
if (i == ZONE_MOVABLE)
continue;
arch_zone_lowest_possible_pfn[i] =
arch_zone_highest_possible_pfn[i-1];
As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone will
be set to zero. This patch fixes this bug by adding explicitly tracking
where the next zone should start rather than relying on the contents
arch_zone_highest_possible_pfn[].
Thie is low priority. To get bitten by this you need to enable a zone
that appears after ZONE_MOVABLE in the zone_type enum. As far as I can
tell this means running a kernel with ZONE_DEVICE or ZONE_CMA enabled,
so I can't see this affecting too many people.
I only noticed this because I've been fiddling with ZONE_DEVICE on
powerpc and 4.6 broke my test kernel. This bug, in conjunction with the
changes in Taku Izumi's kernelcore=mirror patch (d91749c1dda71) and
powerpc being the odd architecture which initialises max_zone_pfn[] to
~0ul instead of 0 caused all of system memory to be placed into
ZONE_DEVICE at boot, followed a panic since device memory cannot be used
for kernel allocations. I've already submitted a patch to fix the
powerpc specific bits, but I figured this should be fixed too.
Link: http://lkml.kernel.org/r/1462435033-15601-1-git-send-email-oohall@gmail.com
Signed-off-by: Oliver O'Halloran <oohall@gmail.com>
Cc: Anton Blanchard <anton@samba.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 8b3e134..8129922 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -6467,15 +6467,18 @@ void __init free_area_init_nodes(unsigned long *max_zone_pfn)
sizeof(arch_zone_lowest_possible_pfn));
memset(arch_zone_highest_possible_pfn, 0,
sizeof(arch_zone_highest_possible_pfn));
- arch_zone_lowest_possible_pfn[0] = find_min_pfn_with_active_regions();
- arch_zone_highest_possible_pfn[0] = max_zone_pfn[0];
- for (i = 1; i < MAX_NR_ZONES; i++) {
+
+ start_pfn = find_min_pfn_with_active_regions();
+
+ for (i = 0; i < MAX_NR_ZONES; i++) {
if (i == ZONE_MOVABLE)
continue;
- arch_zone_lowest_possible_pfn[i] =
- arch_zone_highest_possible_pfn[i-1];
- arch_zone_highest_possible_pfn[i] =
- max(max_zone_pfn[i], arch_zone_lowest_possible_pfn[i]);
+
+ end_pfn = max(max_zone_pfn[i], start_pfn);
+ arch_zone_lowest_possible_pfn[i] = start_pfn;
+ arch_zone_highest_possible_pfn[i] = end_pfn;
+
+ start_pfn = end_pfn;
}
arch_zone_lowest_possible_pfn[ZONE_MOVABLE] = 0;
arch_zone_highest_possible_pfn[ZONE_MOVABLE] = 0;
^ permalink raw reply related [flat|nested] 3+ messages in thread