Hi James, On 03/30/20 at 06:17pm, James Morse wrote: > Hi Baoquan, > > On 3/30/20 2:55 PM, Baoquan He wrote: > > On 03/26/20 at 06:07pm, 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. > > > > I talked about this with Dave Young. Currently, we tend to use > > kexec_file_load more in the future since most of its implementation is > > in kernel, we can get information about kernel more easilier. For the > > kexec kernel loaded into hotpluggable area, we can fix it in > > kexec_file_load side, we know the MOVABLE zone's start and end. As for > > the old kexec_load, we would like to keep it for back compatibility. At > > least in our distros, we have switched to kexec_file_load, will > > gradually obsolete kexec_load. > > > So for this one, I suggest avoiding those > > MOVZBLE memory region when searching place for kexec kernel. > > How does today's user-space know? > > > > Not sure if arm64 will still have difficulty. > > arm64 added support for kexec_load first, then kexec_file_load. (evidently a > mistake). > kexec_file_load support was only added in the last year or so, I'd hazard most > people using this, are using the regular load kind. (and probably don't know or > care). I agreed that file load is still not widely used, but in the long run we should not maintain both of them all the future time. Especially when some kernel-userspace interfaces need to be introduced, file load will have the natural advantage. We may keep the kexec_load for other misc usecases, but we can use file load for the major modern linux-to-linux loading. I'm not saying we can do it immediately, just thought we should reduce the duplicate effort and try to avoid hacking if possible. Anyway about this particular issue, I wonder if we can just reload with a udev rule as replied in another mail. Thanks Dave _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
