The patch titled
Subject: mm/hotplug: reorder memblock_[free|remove]() calls in try_remove_memory()
has been added to the -mm tree. Its filename is
mm-hotplug-reorder-memblock_-calls-in-try_remove_memory.patch
This patch should soon appear at
http://ozlabs.org/~akpm/mmots/broken-out/mm-hotplug-reorder-memblock_-calls-in-try_remove_memory.patch
and later at
http://ozlabs.org/~akpm/mmotm/broken-out/mm-hotplug-reorder-memblock_-calls-in-try_remove_memory.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: Anshuman Khandual <anshuman.khandual@xxxxxxx>
Subject: mm/hotplug: reorder memblock_[free|remove]() calls in try_remove_memory()
Currently during memory hot add procedure, memory gets into memblock
before calling arch_add_memory() which creates its linear mapping.
add_memory_resource() {
..................
memblock_add_node()
..................
arch_add_memory()
..................
}
But during memory hot remove procedure, removal from memblock happens
first before its linear mapping gets teared down with arch_remove_memory()
which is not consistent. Resource removal should happen in reverse order
as they were added. However this does not pose any problem for now,
unless there is an assumption regarding linear mapping. One example was a
subtle failure on arm64 platform [1]. Though this has now found a
different solution.
try_remove_memory() {
..................
memblock_free()
memblock_remove()
..................
arch_remove_memory()
..................
}
This changes the sequence of resource removal including memblock and
linear mapping tear down during memory hot remove which will now be the
reverse order in which they were added during memory hot add. The changed
removal order looks like the following.
try_remove_memory() {
..................
arch_remove_memory()
..................
memblock_free()
memblock_remove()
..................
}
[1] https://patchwork.kernel.org/patch/11127623/
Memory hot remove now works on arm64 without this because a recent commit
60bb462fc7ad ("drivers/base/node.c: simplify
unregister_memory_block_under_nodes()").
David mentioned that re-ordering should still make sense for consistency
purpose (removing stuff in the reverse order they were added). This patch
is now detached from arm64 hot-remove series.
Link: http://lkml.kernel.org/r/1569380273-7708-1-git-send-email-anshuman.khandual@xxxxxxx
Signed-off-by: Anshuman Khandual <anshuman.khandual@xxxxxxx>
Cc: Oscar Salvador <osalvador@xxxxxxx>
Cc: Michal Hocko <mhocko@xxxxxxxx>
Cc: David Hildenbrand <david@xxxxxxxxxx>
Cc: Pavel Tatashin <pasha.tatashin@xxxxxxxxxx>
Cc: Dan Williams <dan.j.williams@xxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
mm/memory_hotplug.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/memory_hotplug.c~mm-hotplug-reorder-memblock_-calls-in-try_remove_memory
+++ a/mm/memory_hotplug.c
@@ -1774,13 +1774,13 @@ static int __ref try_remove_memory(int n
/* remove memmap entry */
firmware_map_remove(start, start + size, "System RAM");
- memblock_free(start, size);
- memblock_remove(start, size);
/* remove memory block devices before removing memory */
remove_memory_block_devices(start, size);
arch_remove_memory(nid, start, size, NULL);
+ memblock_free(start, size);
+ memblock_remove(start, size);
__release_memory_resource(start, size);
try_offline_node(nid);
_
Patches currently in -mm which might be from anshuman.khandual@xxxxxxx are
mm-memremap-drop-unused-section_size-and-section_mask.patch
mm-hotplug-reorder-memblock_-calls-in-try_remove_memory.patch
