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
