Received: by 10.213.65.68 with SMTP id h4csp1020061imn; Wed, 14 Mar 2018 07:18:54 -0700 (PDT) X-Google-Smtp-Source: AG47ELvJPnMR5DuVwVCZ7CMpAuAO+Ss35oyBxgoplzjOajDqAXMcgxZqBX3+IGCXd2B6T5Bp08U1 X-Received: by 10.99.37.7 with SMTP id l7mr3968929pgl.212.1521037134471; Wed, 14 Mar 2018 07:18:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521037134; cv=none; d=google.com; s=arc-20160816; b=UQ9DfiA+b5G2TX0AdQNVxJZqZvw+tdtl1CERRZieFmTLUdZxlFrxtVZnuJLhNbgYtD A4C4AN2yZEY5jW9VsHmxjJFL7Pb3F4V9kRBHhF+BeQ4TUWL7gMuJ44SYcr8ra++mL+Os 6rOjwu8A4bk6w+e+qwqxPnqkRSJZqPNXCLG1B+m4pv+2kYobjo1gHCr3rB4H2eIyKXGf +m6mSWxR5F+MTDHNA1BvSiQNJc3IR2LGxLEcnVMypXPw06I4wZFUcj/NpHzFwqFmNeci 64tZT+40tIAJWGQyH6UzO1UE89+piZkjfV3eCP/WXuJ6VDp3AfL8RDKB8eULFvesJcO0 cn0A== 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=oL4Q96enz/LoUor/DI2ZtJpoUVzxAcPBZu52OJElEeQ=; b=bBYzla5LwED6iCFk6HC0VpWNQ2rfk8G61nqzPpTUdy3jh9zVLZxcP1qR2z9+YgzjO8 0cSvSb07imyzO6CJkYKXpDemA/UvhO2SwEDPZonAqaaiSxufITnzBTtJ+4OBVzT5gic2 SrMX3n1LXNTJs5Dcc305S/LZ/zN7RLCkHhahe2RD0vM9/klqjFabtkGiXQSQiUSXmNjf pdgj95ggKOveM3A898liNDjj56mWzdBYPqOj7fKcP2EUjJkRQ9zo0vQEZLEzhFX3vNoA nwZGQpvaoyfJAQqNx7O192VHuKS6BHgN2YJpIdB1Crzsog3WMwNquCC6Abc+HLZtmCBA RcEA== 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 e5si2194416pfl.5.2018.03.14.07.18.37; Wed, 14 Mar 2018 07:18:54 -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 S1751440AbeCNORb (ORCPT + 99 others); Wed, 14 Mar 2018 10:17:31 -0400 Received: from mx2.suse.de ([195.135.220.15]:33228 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750779AbeCNOR3 (ORCPT ); Wed, 14 Mar 2018 10:17:29 -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 23CA0ADF9; Wed, 14 Mar 2018 14:17:28 +0000 (UTC) Date: Wed, 14 Mar 2018 15:17:27 +0100 From: Michal Hocko To: Daniel Vacek Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, Sudeep Holla , Naresh Kamboju , Andrew Morton , Mel Gorman , Paul Burton , Pavel Tatashin , Vlastimil Babka , stable@vger.kernel.org Subject: Re: [PATCH] mm/page_alloc: fix boot hang in memmap_init_zone Message-ID: <20180314141727.GE23100@dhcp22.suse.cz> References: <20180313224240.25295-1-neelx@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180313224240.25295-1-neelx@redhat.com> 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 On Tue 13-03-18 23:42:40, Daniel Vacek wrote: > On some architectures (reported on arm64) commit 864b75f9d6b01 ("mm/page_alloc: fix memmap_init_zone pageblock alignment") > causes a boot hang. This patch fixes the hang making sure the alignment > never steps back. I am sorry to be complaining again, but the code is so obscure that I would _really_ appreciate some more information about what is going on here. memblock_next_valid_pfn will most likely return a pfn within the same memblock and the alignment will move it before the old pfn which is not valid - so the block has some holes. Is that correct? If yes then please put it into the changelog. Maybe reuse data provided by Arnd http://lkml.kernel.org/r/20180314134431.13241-1-ard.biesheuvel@linaro.org > Link: http://lkml.kernel.org/r/0485727b2e82da7efbce5f6ba42524b429d0391a.1520011945.git.neelx@redhat.com > Fixes: 864b75f9d6b01 ("mm/page_alloc: fix memmap_init_zone pageblock alignment") > Signed-off-by: Daniel Vacek > Tested-by: Sudeep Holla > Tested-by: Naresh Kamboju > Cc: Andrew Morton > Cc: Mel Gorman > Cc: Michal Hocko > Cc: Paul Burton > Cc: Pavel Tatashin > Cc: Vlastimil Babka > Cc: > --- > mm/page_alloc.c | 7 ++++++- > 1 file changed, 6 insertions(+), 1 deletion(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 3d974cb2a1a1..e033a6895c6f 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -5364,9 +5364,14 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, > * is not. move_freepages_block() can shift ahead of > * the valid region but still depends on correct page > * metadata. > + * Also make sure we never step back. > */ > - pfn = (memblock_next_valid_pfn(pfn, end_pfn) & > + unsigned long next_pfn; > + > + next_pfn = (memblock_next_valid_pfn(pfn, end_pfn) & > ~(pageblock_nr_pages-1)) - 1; > + if (next_pfn > pfn) > + pfn = next_pfn; > #endif > continue; > } > -- > 2.16.2 > -- Michal Hocko SUSE Labs