The patch titled
Subject: mm/page_alloc.c: fix calculation of pgdat->nr_zones
has been added to the -mm tree. Its filename is
mm-page_alloc-fix-calculation-of-pgdat-nr_zones.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-page_alloc-fix-calculation-of-pgdat-nr_zones.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-page_alloc-fix-calculation-of-pgdat-nr_zones.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next and is updated
there every 3-4 working days
------------------------------------------------------
From: Wei Yang <richard.weiyang@xxxxxxxxx>
Subject: mm/page_alloc.c: fix calculation of pgdat->nr_zones
init_currently_empty_zone() will adjust pgdat->nr_zones and set it to
'zone_idx(zone) + 1' unconditionally. This is correct in the normal case,
while not exact in hot-plug situation.
This function is used in two places:
* free_area_init_core()
* move_pfn_range_to_zone()
In the first case, we are sure zone index increase monotonically. While
in the second one, this is under users control.
One way to reproduce this is:
----------------------------
1. create a virtual machine with empty node1
-m 4G,slots=32,maxmem=32G \
-smp 4,maxcpus=8 \
-numa node,nodeid=0,mem=4G,cpus=0-3 \
-numa node,nodeid=1,mem=0G,cpus=4-7
2. hot-add cpu 3-7
cpu-add [3-7]
2. hot-add memory to nod1
object_add memory-backend-ram,id=ram0,size=1G
device_add pc-dimm,id=dimm0,memdev=ram0,node=1
3. online memory with following order
echo online_movable > memory47/state
echo online > memory40/state
After this, node1 will have its nr_zones equals to (ZONE_NORMAL + 1)
instead of (ZONE_MOVABLE + 1).
Michal said:
: Having an incorrect nr_zones might result in all sorts of problems which
: would be quite hard to debug (e.g. reclaim not considering the movable
: zone). I do not expect many users would suffer from this it but still
: this is trivial and obviously right thing to do so backporting to the
: stable tree shouldn't be harmful (last famous words).
Link: http://lkml.kernel.org/r/20181117022022.9956-1-richard.weiyang@xxxxxxxxx
Fixes: f1dd2cd13c4b ("mm, memory_hotplug: do not associate hotadded memory to zones until online")
Signed-off-by: Wei Yang <richard.weiyang@xxxxxxxxx>
Acked-by: Michal Hocko <mhocko@xxxxxxxx>
Reviewed-by: Oscar Salvador <osalvador@xxxxxxx>
Cc: Anshuman Khandual <anshuman.khandual@xxxxxxx>
Cc: Dave Hansen <dave.hansen@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
--- a/mm/page_alloc.c~mm-page_alloc-fix-calculation-of-pgdat-nr_zones
+++ a/mm/page_alloc.c
@@ -5813,8 +5813,10 @@ void __meminit init_currently_empty_zone
unsigned long size)
{
struct pglist_data *pgdat = zone->zone_pgdat;
+ int zone_idx = zone_idx(zone) + 1;
- pgdat->nr_zones = zone_idx(zone) + 1;
+ if (zone_idx > pgdat->nr_zones)
+ pgdat->nr_zones = zone_idx;
zone->zone_start_pfn = zone_start_pfn;
_
Patches currently in -mm which might be from richard.weiyang@xxxxxxxxx are
mm-page_alloc-fix-calculation-of-pgdat-nr_zones.patch
mm-slub-remove-validation-on-cpu_slab-in-__flush_cpu_slab.patch
mm-slub-page-is-always-non-null-for-node_match.patch
mm-slub-record-final-state-of-slub-action-in-deactivate_slab.patch
mm-slub-improve-performance-by-skipping-checked-node-in-get_any_partial.patch
mm-remove-reset-of-pcp-counter-in-pageset_init.patch
vmscan-return-node_reclaim_noscan-in-node_reclaim-when-config_numa-is-n.patch
