Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image

[David Hildenbrand <david@redhat.com>]

On 27.03.20 17:56, James Morse wrote:
> 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@arm.com>
>>> ---
>>>  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...

Let's recap

1. You load the image. You allocate memory for e.g., the kexec kernel.
The pages will be marked PG_reserved, so they cannot be offlined.

2. You do the kexec. The kexec kernel will only operate on a reserved
memory region (reserved via e.g., kernel cmdline crashkernel=128M).

Is it that in 2., the reserved memory region (for the crashkernel) could
have been offlined in the meantime?

-- 
Thanks,

David / dhildenb