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@xxxxxxxxxxxxx> > Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > Cc: Dan Williams <dan.j.williams@xxxxxxxxx> > Cc: Michal Hocko <mhocko@xxxxxxxx> > 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
