Re: [PATCH for 4.19-stable v3 00/24] mm/memory_hotplug: backport of pending stable fixes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 28.01.20 14:50, Greg Kroah-Hartman wrote:
> 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.

Will do, should happen anytime soon. Thanks!


-- 
Thanks,

David / dhildenb





[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux