On Thu, May 26, 2016 at 02:21:42PM -0700, Andrew Morton wrote: > On Thu, 5 May 2016 17:57:13 +1000 "Oliver O'Halloran" <oohall@xxxxxxxxx> wrote: > > > As a part of memory initialisation the architecture passes an array to > > free_area_init_nodes() which specifies the max PFN of each memory zone. > > This array is not necessarily monotonic (due to unused zones) so this > > array is parsed to build monotonic lists of the min and max PFN for > > each zone. ZONE_MOVABLE is special cased here as its limits are managed by > > the mm subsystem rather than the architecture. Unfortunately, this special > > casing is broken when ZONE_MOVABLE is the not the last zone in the zone > > list. The core of the issue is: > > > > if (i == ZONE_MOVABLE) > > continue; > > arch_zone_lowest_possible_pfn[i] = > > arch_zone_highest_possible_pfn[i-1]; > > > > As ZONE_MOVABLE is skipped the lowest_possible_pfn of the next zone > > will be set to zero. This patch fixes this bug by adding explicitly > > tracking where the next zone should start rather than relying on the > > contents arch_zone_highest_possible_pfn[]. > > hm, this is all ten year old Mel code. > ZONE_MOVABLE at the time always existed at the end of a node during initialisation time. It was allowed because the memory was always "stolen" from the end of the node where it could have the same limitations as ZONE_HIGHMEM if necessary. It was also safe to assume that zones never overlapped as zones were about addressing limitations. If ZONE_CMA or ZONE_DEVICE can overlap with other zones during initialisation time then there may be a few gremlins hiding in there. Unfortunately I have not done an audit searching for problems with overlapping zones. -- Mel Gorman SUSE Labs -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>