On Tue, Jan 28, 2020 at 10:49:57AM +0100, David Hildenbrand wrote:
> This is the backport of the following fixes for 4.19-stable:
>
> - d84f2f5a7552 ("drivers/base/node.c: simplify
> unregister_memory_block_under_nodes()")
> -- Turned out to not only be a cleanup but also a fix
> - 2c91f8fc6c99 ("mm/memory_hotplug: fix try_offline_node()")
> -- Automatic stable backport failed due to missing dependencies.
> - feee6b298916 ("mm/memory_hotplug: shrink zones when offlining memory")
> -- Was marked as stable 5.0+ due to the backport complexity,, but it's also
> relevant for 4.19/4.14. As I have to backport quite some cleanups
> already ...
>
> All tackle memory unplug issues, especially when memory was never
> onlined (or onlining failed), paired with memory unplug. When trying to
> access garbage memmaps we crash the kernel (e.g., because the derviced
> pgdat pointer is broken)
>
> To minimize manual code changes, I decided to pull in quite some cleanups.
> Still some manual code changes are necessary (indicated in the individual
> patches). Especially missing arm64 hot(un)plug, missing sub-section hotadd
> support, and missing unification of mm/hmm.c and kernel/memremap.c requires
> care.
>
> Due to:
> - 4e0d2e7ef14d ("mm, sparse: pass nid instead of pgdat to
> sparse_add_one_section()")
> I need:
> - afe9b36ca890 ("mm/memunmap: don't access uninitialized memmap in
> memunmap_pages()")
>
> Please note that:
> - 4c4b7f9ba948 ("mm/memory_hotplug: remove memory block devices
> before arch_remove_memory()")
> Makes big (e.g., 32TB) machines boot up slower (e.g., 2h vs 10m). There is
> a performance fix in linux-next, but it does not seem to classify as a
> fix for current RC / stable.
If this is that big of a regression, yes, it does classify as a fix and
is ok for the stable trees. Please let me know what that git id is when
it hits Linus's tree.
> I did quite some testing with hot(un)plug, onlining/offlining of memory
> blocks and memory-less/CPU-less NUMA nodes under x86_64 - the same set of
> tests I run against upstream on a fairly regular basis. I compile-tested
> on PowerPC, arm64, s390x, i386 and sh. I did not test any ZONE_DEVICE/HMM
> thingies.
>
> The 4.14 backport might take a bit - it would be quite a lot of patches
> to backport and it is not that severely broken, so I am thinking about
> simpler (less invasive) alternatives.
All now queued up, thanks.
greg k-h
