Thread (11 messages) 11 messages, 3 authors, 2019-11-04

Re: [PATCH V9 2/2] arm64/mm: Enable memory hot remove

From: Catalin Marinas <catalin.marinas@arm.com>
Date: 2019-10-18 09:48:59
Also in: lkml

On Fri, Oct 11, 2019 at 08:26:32AM +0530, Anshuman Khandual wrote:
On 10/10/2019 05:04 PM, Catalin Marinas wrote:
quoted
Mark Rutland mentioned at some point that, as a preparatory patch to
this series, we'd need to make sure we don't hot-remove memory already
given to the kernel at boot. Any plans here?
Hmm, this series just enables platform memory hot remove as required from
generic memory hotplug framework. The path here is triggered either from
remove_memory() or __remove_memory() which takes physical memory range
arguments like (nid, start, size) and do the needful. arch_remove_memory()
should never be required to test given memory range for anything including
being part of the boot memory.
Assuming arch_remove_memory() doesn't (cannot) check, is there a risk on
arm64 that, for example, one removes memory available at boot and then
kexecs a new kernel? Does the kexec tool present the new kernel with the
original memory map?

I can see x86 has CONFIG_FIRMWARE_MEMMAP suggesting that it is used by
kexec. try_remove_memory() calls firmware_map_remove() so maybe they
solve this problem differently.

Correspondingly, after an arch_add_memory(), do we want a kexec kernel
to access it? x86 seems to use the firmware_map_add_hotplug() mechanism.

Adding James as well for additional comments on kexec scenarios.
IIUC boot memory added to system with memblock_add() lose all it's identity
after the system is up and running. In order to reject any attempt to hot
remove boot memory, platform needs to remember all those memory that came
early in the boot and then scan through it during arch_remove_memory().

Ideally, it is the responsibility of [_]remove_memory() callers like ACPI
driver, DAX etc to make sure they never attempt to hot remove a memory
range, which never got hot added by them in the first place. Also, unlike
/sys/devices/system/memory/probe there is no 'unprobe' interface where the
user can just trigger boot memory removal. Hence, unless there is a bug in
ACPI, DAX or other callers, there should never be any attempt to hot remove
boot memory in the first place.
That's fine if these callers give such guarantees. I just want to make
sure someone checked all the possible scenarios for memory hot-remove.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help