Re: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use

[David Hildenbrand <david@redhat.com>]

On 27.03.20 16:42, James Morse wrote:
> Hi David,
> 
> On 3/27/20 9:27 AM, David Hildenbrand wrote:
>> On 26.03.20 19:07, James Morse wrote:
>>> 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.
> 
>> IIRC other architectures handle that by setting the affected pages
>> PageReserved. Any reason why to not stick to the same?
> 
> Hmm, I didn't spot this. How come core code doesn't do it if its needed?
> 
> Doesn't PG_Reserved prevent the page from being used for regular allocations?
> (or is that only if its done early)
> 
> I prefer the runtime check as the dmesg output gives the user some chance of
> knowing why their memory-offline failed, and doing something about it!

I was confused which memory we are trying to protect. Understood now,
that you are dealing with the target physical memory described during
described during kexec_load.

[...]

> 
>> Also, makedumpfile will check if the
>> sections are still around IIRC.
> 
> Curious. I thought the vmcore was virtually addressed, how does it know which
> linear-map portions correspond to sysfs memory nodes with KASLR?

That's a very interesting question. I remember there was KASLR support
being implemented specifically for that - but I don't know any details.

>> Not sure what you mean by "Unaware kdump from user-space".
> 
> The existing kexec-tools binaries, that (I assume) don't go probing to find out
> if 'System RAM' is removable or not, loading a kdump kernel, along with the
> user-space generated blob that describes the first kernel's memory usage to the
> second kernel.

Finally understood how kexec without kdump works, thanks.

-- 
Thanks,

David / dhildenb