Received: by 10.213.65.68 with SMTP id h4csp1018871imn; Wed, 14 Mar 2018 07:16:47 -0700 (PDT) X-Google-Smtp-Source: AG47ELvTJbMNHLUq5NS72NiJzI2ZgrarKka5bItmpIzbUUkVZfcdbz+thUKlbvGI7xeegBZmt0+/ X-Received: by 10.98.252.22 with SMTP id e22mr4430166pfh.235.1521037007601; Wed, 14 Mar 2018 07:16:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521037007; cv=none; d=google.com; s=arc-20160816; b=y/qXkiEtnsIeHqAATqegqklE4wff3bgbFcmpS7bY1I3Y2IOsmvDXGuoSKviaFAFW// IdWdX9HKbgsB1fjkONbWZs5d+DYRJoxQkICtc2BKnwGPUP47zki1+eX2l1CT5rVTu249 10na/kP9D+0sAVfRotKo/hQIytN1lCWW6dC6aYHlPqOuoq0vT3PGq+Y+AOOsFNgVa0yT +7CafYN0SXTKtaUHnL1PnXuQnmAFcYGqjR0INJvGcK3Be1lAmAQRslo/mwF55yTC1QKh FwXyaH8xw287jnxmz0lJ5Ke3w5+Ev8zWgJXIQtue34xz1K1hmOxE+gIv5p+0Xt1vl4Zj ytUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=pkxZc1OqTKQjiBkQNQZxEzmKIBrmj2OFytE+7wxoQaE=; b=Gw0fkpgyAF+LOZa7M8At0SgwazpeIb73v3KET/DRtg9jOtWru0Hm1g3xgxs+eNnI1S y193WLEgCfqt74g/NqvGmMwT5xIochsLr6jAnGMQRni5gC0RqUa2+Zs1ri0jxHjdach7 gejzh0njHsEYr/xFb0cvkUVQvY2wo1cJc/TGiuZlXYtvsY0jhcVMS4XOU7MRsHCepwS+ 1nukDxfM+44nfPQtJRXJxsIpaG0aBNbk5l2rFrHRP+xVZbC1OLBuCDoN7uFtLpUeuQp2 mmDAQkxJH78A1NhvkWxxY2mq+H/73Gguy7IsjKb+gCpAVYmOEBCV9H+XJnnKI5+P2Hda C/WA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g3si1887842pgc.14.2018.03.14.07.16.29; Wed, 14 Mar 2018 07:16:47 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751901AbeCNON1 (ORCPT + 99 others); Wed, 14 Mar 2018 10:13:27 -0400 Received: from mx2.suse.de ([195.135.220.15]:60786 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751405AbeCNON0 (ORCPT ); Wed, 14 Mar 2018 10:13:26 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id 8114DAE7C; Wed, 14 Mar 2018 14:13:24 +0000 (UTC) Date: Wed, 14 Mar 2018 15:13:23 +0100 From: Michal Hocko To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, mark.rutland@arm.com, will.deacon@arm.com, catalin.marinas@arm.com, marc.zyngier@arm.com, Daniel Vacek , Mel Gorman , Paul Burton , Pavel Tatashin , Vlastimil Babka , Andrew Morton , Linus Torvalds Subject: Re: [PATCH] Revert "mm/page_alloc: fix memmap_init_zone pageblock alignment" Message-ID: <20180314141323.GD23100@dhcp22.suse.cz> References: <20180314134431.13241-1-ard.biesheuvel@linaro.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180314134431.13241-1-ard.biesheuvel@linaro.org> User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Does http://lkml.kernel.org/r/20180313224240.25295-1-neelx@redhat.com fix your issue? From the debugging info you provided it should because the patch prevents jumping backwards. On Wed 14-03-18 13:44:31, Ard Biesheuvel wrote: > This reverts commit 864b75f9d6b0100bb24fdd9a20d156e7cda9b5ae. > > It breaks the boot on my Socionext SynQuacer based system, because > it enters an infinite loop iterating over the pfns. > > Adding the following debug output to memmap_init_zone() > > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5365,6 +5365,11 @@ > * the valid region but still depends on correct page > * metadata. > */ > + pr_err("pfn:%lx oldnext:%lx newnext:%lx\n", pfn, > + memblock_next_valid_pfn(pfn, end_pfn) - 1, > + (memblock_next_valid_pfn(pfn, end_pfn) & > + ~(pageblock_nr_pages-1)) - 1); > + > pfn = (memblock_next_valid_pfn(pfn, end_pfn) & > ~(pageblock_nr_pages-1)) - 1; > #endif > > results in > > Booting Linux on physical CPU 0x0000000000 [0x410fd034] > Linux version 4.16.0-rc5-00004-gfc6eabbbf8ef-dirty (ard@dogfood) ... > Machine model: Socionext Developer Box > earlycon: pl11 at MMIO 0x000000002a400000 (options '') > bootconsole [pl11] enabled > efi: Getting EFI parameters from FDT: > efi: EFI v2.70 by Linaro > efi: SMBIOS 3.0=0xff580000 ESRT=0xf9948198 MEMATTR=0xf83b1a98 RNG=0xff7ac898 > random: fast init done > efi: seeding entropy pool > esrt: Reserving ESRT space from 0x00000000f9948198 to 0x00000000f99481d0. > cma: Reserved 16 MiB at 0x00000000fd800000 > NUMA: No NUMA configuration found > NUMA: Faking a node at [mem 0x0000000000000000-0x0000000fffffffff] > NUMA: NODE_DATA [mem 0xffffd8d80-0xffffda87f] > Zone ranges: > DMA32 [mem 0x0000000080000000-0x00000000ffffffff] > Normal [mem 0x0000000100000000-0x0000000fffffffff] > Movable zone start for each node > Early memory node ranges > node 0: [mem 0x0000000080000000-0x00000000febeffff] > node 0: [mem 0x00000000febf0000-0x00000000fefcffff] > node 0: [mem 0x00000000fefd0000-0x00000000ff43ffff] > node 0: [mem 0x00000000ff440000-0x00000000ff7affff] > node 0: [mem 0x00000000ff7b0000-0x00000000ffffffff] > node 0: [mem 0x0000000880000000-0x0000000fffffffff] > Initmem setup node 0 [mem 0x0000000080000000-0x0000000fffffffff] > pfn:febf0 oldnext:febf0 newnext:fe9ff > pfn:febf0 oldnext:febf0 newnext:fe9ff > pfn:febf0 oldnext:febf0 newnext:fe9ff > etc etc > > and the boot never proceeds after this point. > > So the logic is obviously flawed, and so it is best to revert this at > the current -rc stage (unless someone can fix the logic instead) > > Fixes: 864b75f9d6b0 ("mm/page_alloc: fix memmap_init_zone pageblock alignment") > Cc: Daniel Vacek > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Paul Burton > Cc: Pavel Tatashin > Cc: Vlastimil Babka > Cc: Andrew Morton > Cc: Linus Torvalds > Signed-off-by: Ard Biesheuvel > --- > mm/page_alloc.c | 9 ++------- > 1 file changed, 2 insertions(+), 7 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 3d974cb2a1a1..cb416723538f 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5359,14 +5359,9 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, > /* > * Skip to the pfn preceding the next valid one (or > * end_pfn), such that we hit a valid pfn (or end_pfn) > - * on our next iteration of the loop. Note that it needs > - * to be pageblock aligned even when the region itself > - * is not. move_freepages_block() can shift ahead of > - * the valid region but still depends on correct page > - * metadata. > + * on our next iteration of the loop. > */ > - pfn = (memblock_next_valid_pfn(pfn, end_pfn) & > - ~(pageblock_nr_pages-1)) - 1; > + pfn = memblock_next_valid_pfn(pfn, end_pfn) - 1; > #endif > continue; > } > -- > 2.15.1 > -- Michal Hocko SUSE Labs