On 5/5/20 6:18 AM, Guenter Roeck wrote: > On 5/4/20 8:39 AM, Mike Rapoport wrote: >> On Sun, May 03, 2020 at 11:43:00AM -0700, Guenter Roeck wrote: >>> On Sun, May 03, 2020 at 10:41:38AM -0700, Guenter Roeck wrote: >>>> Hi, >>>> >>>> On Wed, Apr 29, 2020 at 03:11:23PM +0300, Mike Rapoport wrote: >>>>> From: Mike Rapoport <rppt@xxxxxxxxxxxxx> >>>>> >>>>> Some architectures (e.g. ARC) have the ZONE_HIGHMEM zone below the >>>>> ZONE_NORMAL. Allowing free_area_init() parse max_zone_pfn array even it is >>>>> sorted in descending order allows using free_area_init() on such >>>>> architectures. >>>>> >>>>> Add top -> down traversal of max_zone_pfn array in free_area_init() and use >>>>> the latter in ARC node/zone initialization. >>>>> >>>>> Signed-off-by: Mike Rapoport <rppt@xxxxxxxxxxxxx> >>>> This patch causes my microblazeel qemu boot test in linux-next to fail. >>>> Reverting it fixes the problem. >>>> >>> The same problem is seen with s390 emulations. >> Yeah, this patch breaks some others as well :( >> >> My assumption that max_zone_pfn defines architectural limit for maximal >> PFN that can belong to a zone was over-optimistic. Several arches >> actually do that, but others do >> >> max_zone_pfn[ZONE_DMA] = MAX_DMA_PFN; >> max_zone_pfn[ZONE_NORMAL] = max_pfn; >> >> where MAX_DMA_PFN is build-time constrain and max_pfn is run time limit >> for the current system. >> >> So, when max_pfn is lower than MAX_DMA_PFN, the free_init_area() will >> consider max_zone_pfn as descending and will wrongly calculate zone >> extents. >> >> That said, instead of trying to create a generic way to special case >> ARC, I suggest to simply use the below patch instead. >> > As a reminder, I reported the problem against s390 and microblazeel > (interestingly enough, microblaze (big endian) works), not against arc. Understood and my comment was to point to any other problems in future. Thx, -Vineet
