Hi David, On 3/27/20 9:30 AM, David Hildenbrand wrote: > On 26.03.20 19:07, James Morse wrote: >> An image loaded for kexec is not stored in place, instead its segments >> are scattered through memory, and are re-assembled when needed. In the >> meantime, the target memory may have been removed. >> >> Because mm is not aware that this memory is still in use, it allows it >> to be removed. >> >> Add a memory notifier to prevent the removal of memory regions that >> overlap with a loaded kexec image segment. e.g., when triggered from the >> Qemu console: >> | kexec_core: memory region in use >> | memory memory32: Offline failed. >> >> Signed-off-by: James Morse <james.morse@xxxxxxx> >> --- >> kernel/kexec_core.c | 56 +++++++++++++++++++++++++++++++++++++++++++++ >> 1 file changed, 56 insertions(+) >> >> diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c >> index c19c0dad1ebe..ba1d91e868ca 100644 >> --- a/kernel/kexec_core.c >> +++ b/kernel/kexec_core.c > E.g., in kernel/kexec_core.c:kimage_alloc_pages() > > "SetPageReserved(pages + i);" > > Pages that are reserved cannot get offlined. How are you able to trigger > that before this patch? (where is the allocation path for kexec, which > will not set the pages reserved?) This sets page reserved on the memory it gets back from alloc_pages() in kimage_alloc_pages(). This is when you load the image[0]. The problem I see is for the target or destination memory once you execute the image. Once machine_kexec() runs, it tries to write to this, assuming it is still present... How can I make the commit message clearer? 're-assembled' and 'target memory' aren't quite cutting it, is there are a correct term to use? (destination?) Thanks, James [0] Just to convince myself: | kimage_alloc_pages+0x30/0x15c | kimage_alloc_page+0x210/0x7d8 | kimage_load_segment+0x14c/0x8c8 | __arm64_sys_kexec_load+0x4f0/0x720 | do_el0_svc+0x13c/0x3c0 | el0_sync_handler+0x9c/0x3c0 | el0_sync+0x158/0x180
