Hello!
arm64 recently queued support for memory hotremove, which led to some
new corner cases for kexec.
If the kexec segments are loaded for a removable region, that region may
be removed before kexec actually occurs. This causes the first kernel to
lockup when applying the relocations. (I've triggered this on x86 too).
The first patch adds a memory notifier for kexec so that it can refuse
to allow in-use regions to be taken offline.
This doesn't solve the problem for arm64, where the new kernel must
initially rely on the data structures from the first boot to describe
memory. These don't describe hotpluggable memory.
If kexec places the kernel in one of these regions, it must also provide
a DT that describes the region in which the kernel was mapped as memory.
(and somehow ensure its always present in the future...)
To prevent this from happening accidentally with unaware user-space,
patches two and three allow arm64 to give these regions a different
name.
This is a change in behaviour for arm64 as memory hotadd and hotremove
were added separately.
I haven't tried kdump.
Unaware kdump from user-space probably won't describe the hotplug
regions if the name is different, which saves us from problems if
the memory is no longer present at kdump time, but means the vmcore
is incomplete.
These patches are based on arm64's for-next/core branch, but can all
be merged independently.
Thanks,
James Morse (3):
kexec: Prevent removal of memory in use by a loaded kexec image
mm/memory_hotplug: Allow arch override of non boot memory resource
names
arm64: memory: Give hotplug memory a different resource name
arch/arm64/include/asm/memory.h | 11 +++++++
kernel/kexec_core.c | 56 +++++++++++++++++++++++++++++++++
mm/memory_hotplug.c | 6 +++-
3 files changed, 72 insertions(+), 1 deletion(-)
--
2.25.1
