[PATCH v6 00/10] mm/memory_hotplug: Shrink zones before removing memory

[David Hildenbrand]

On 06.10.19 10:56, David Hildenbrand wrote:
> This series fixes the access of uninitialized memmaps when shrinking
> zones/nodes and when removing memory. Also, it contains all fixes for
> crashes that can be triggered when removing certain namespace using
> memunmap_pages() - ZONE_DEVICE, reported by Aneesh.
> 
> We stop trying to shrink ZONE_DEVICE, as it's buggy, fixing it would be
> more involved (we don't have SECTION_IS_ONLINE as an indicator), and
> shrinking is only of limited use (set_zone_contiguous() cannot detect
> the ZONE_DEVICE as contiguous).
> 
> We continue shrinking !ZONE_DEVICE zones, however, I reduced the amount of
> code to a minimum. Shrinking is especially necessary to keep
> zone->contiguous set where possible, especially, on memory unplug of
> DIMMs at zone boundaries.
> 
> --------------------------------------------------------------------------
> 
> Zones are now properly shrunk when offlining memory blocks or when
> onlining failed. This allows to properly shrink zones on memory unplug
> even if the separate memory blocks of a DIMM were onlined to different
> zones or re-onlined to a different zone after offlining.
> 
> Example:
> 
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
>         spanned  0
>         present  0
>         managed  0
> :/# echo "online_movable" > /sys/devices/system/memory/memory41/state
> :/# echo "online_movable" > /sys/devices/system/memory/memory43/state
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
>         spanned  98304
>         present  65536
>         managed  65536
> :/# echo 0 > /sys/devices/system/memory/memory43/online
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
>         spanned  32768
>         present  32768
>         managed  32768
> :/# echo 0 > /sys/devices/system/memory/memory41/online
> :/# cat /proc/zoneinfo
> Node 1, zone  Movable
>         spanned  0
>         present  0
>         managed  0
> 
> --------------------------------------------------------------------------
> 
> I tested this with DIMMs on x86. I didn't test the ZONE_DEVICE part.
> 
> v4 -> v6:
> - "mm/memunmap: Don't access uninitialized memmap in memunmap_pages()"
> -- Minimize code changes, rephrase subject and description
> - "mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span()"
> -- Add ifdef to make it compile without ZONE_DEVICE
> 
> v4 -> v5:
> - "mm/memory_hotplug: Don't access uninitialized memmaps in shrink_zone_span()"
> -- Add more details why ZONE_DEVICE is special
> - Include two patches from Aneesh
> -- "mm/memunmap: Use the correct start and end pfn when removing pages
>     from zone"
> -- "mm/memmap_init: Update variable name in memmap_init_zone"
> 
> v3 -> v4:
> - Drop "mm/memremap: Get rid of memmap_init_zone_device()"
> -- As Alexander noticed, it was messy either way
> - Drop "mm/memory_hotplug: Exit early in __remove_pages() on BUGs"
> - Drop "mm: Exit early in set_zone_contiguous() if already contiguous"
> - Drop "mm/memory_hotplug: Optimize zone shrinking code when checking for
>   holes"
> - Merged "mm/memory_hotplug: Remove pages from a zone before removing
>   memory" and "mm/memory_hotplug: Remove zone parameter from
>   __remove_pages()" into "mm/memory_hotplug: Shrink zones when offlining
>   memory"
> - Added "mm/memory_hotplug: Poison memmap in remove_pfn_range_from_zone()"
> - Stop shrinking ZONE_DEVICE
> - Reshuffle patches, moving all fixes to the front. Add Fixes: tags.
> - Change subject/description of various patches
> - Minor changes (too many to mention)
> 
> Cc: Aneesh Kumar K.V <aneesh.kumar at linux.ibm.com>
> Cc: Andrew Morton <akpm at linux-foundation.org>
> Cc: Dan Williams <dan.j.williams at intel.com>
> Cc: Michal Hocko <mhocko at suse.com>
> 

So, patch #1-#4 are already upstream. The other patches have been in
-next for quite a long time, and I (+other RH people) ran excessive
tests on them.

Especially patch #5 is a BUG fix I want to see upstream rather sooner
than later (last know "uninitialized memmap" access).

Andrew decided not to send these for 5.5 due to lack of ack/review -
which is unfortunate, but the right thing to do.

@Michal, @Oscar, can some of you at least have a patch #5 now so we can
proceed with that? (the other patches can stay in -next some time longer)

-- 
Thanks,

David / dhildenb