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! >> This doesn't solve the problem for arm64, where the new kernel must >> initially rely on the data structures from the first boot to describe >> memory. These don't describe hotpluggable memory. >> If kexec places the kernel in one of these regions, it must also provide >> a DT that describes the region in which the kernel was mapped as memory. >> (and somehow ensure its always present in the future...) >> >> To prevent this from happening accidentally with unaware user-space, >> patches two and three allow arm64 to give these regions a different >> name. >> >> This is a change in behaviour for arm64 as memory hotadd and hotremove >> were added separately. >> >> >> I haven't tried kdump. >> Unaware kdump from user-space probably won't describe the hotplug >> regions if the name is different, which saves us from problems if >> the memory is no longer present at kdump time, but means the vmcore >> is incomplete. > Whenever memory is added/removed, kdump.service is to be restarted from > user space, which will fixup the data structures such that kdump will > not try to dump unplugged memory. Cunning. > 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? > 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. 'user-space' here to distinguish all this from kexec_file_load(). Thanks, James
