Received: by 10.213.65.68 with SMTP id h4csp237004imn; Wed, 28 Mar 2018 02:37:40 -0700 (PDT) X-Google-Smtp-Source: AIpwx4+k7Q4uDfK+Rst47GMOnhKh1n+PcKQfcO0FMWuBdBfCE7qqZxEUNIyNA+sV5+JjcA00p8Rr X-Received: by 10.98.5.71 with SMTP id 68mr2321471pff.241.1522229860005; Wed, 28 Mar 2018 02:37:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522229859; cv=none; d=google.com; s=arc-20160816; b=tX2tI4UTDZ45FVX6cw/qYF8phV9AAeZMbGXfuyP+mKTt6EhrqtHU1sTUv7MziKr66R uBDaCPq1lnWk3/UPpdAV0TmS+gLPzPfu/oALY+fYZD70b1/H/m7Nhm+/1ROUIvTWP6op TycdljF0lOrc8CCC3z6gjoY15cnm1R7D+8pCd6N+EBlQwWsmNwCRb/0vl2cZXtr/v6fV xF7vJqvpk5RMLCNyTRQyx1LfnM2gRTU+qZIOYsFOtpvl2FYIEWC/+RZ1SPgZsapVubej 2B+fwu8JrZKHCiLpGvN/CqRZwLDAQzVxkuUaP9kDa/gli6pxy/iHJstpab3/I3xqch8U Fm4w== 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:reply-to:message-id :subject:cc:to:from:date:dkim-signature:arc-authentication-results; bh=hxiq/bleI/RiF1pIcTH/GOo4Dtqmo4x8aQIaJ+XOexY=; b=S8W9zRotbxoVRIR+KK0S+TONcfWjCoV8u2B4S3GC7DSi/PaZq8AI96/5p8UB7yLQPY WwPvJg23xD4qS+actDTEKddhTFh4uZfk060gEhbHzhUHERjFfGihpyupMMDB4Gg4okuz T2E399Oc3nRFnhVVVc8Y1+0p6WFLzm4lG+Ir3Sb8kR+iH+ERzUVEDLzwJCFDIFzBvWOV uewGRZw7G7vE5YtNle7nPXkUWHfOk3hOQDVBHbVwDsT1cUHLGcCtZd5TqJy1L8RQLOwq TSN8JONhKpjppTsLwZ7b5oe4YadFMtZcH1YhodJ4Lhl4rCX5KqVYuvRkbizeSmpse2iN UlVA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FIVeavD/; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o5-v6si3311984plh.432.2018.03.28.02.37.25; Wed, 28 Mar 2018 02:37:39 -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; dkim=pass header.i=@gmail.com header.s=20161025 header.b=FIVeavD/; 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; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752230AbeC1JOL (ORCPT + 99 others); Wed, 28 Mar 2018 05:14:11 -0400 Received: from mail-pg0-f66.google.com ([74.125.83.66]:37368 "EHLO mail-pg0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751903AbeC1JOI (ORCPT ); Wed, 28 Mar 2018 05:14:08 -0400 Received: by mail-pg0-f66.google.com with SMTP id n11so714645pgp.4 for ; Wed, 28 Mar 2018 02:14:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:reply-to:references:mime-version :content-disposition:in-reply-to:user-agent; bh=hxiq/bleI/RiF1pIcTH/GOo4Dtqmo4x8aQIaJ+XOexY=; b=FIVeavD/PxC3ROIzwVH+jdXGzZcgrBCFwpMJ+llxF1ePkzKIkp8Dblvw5yEYhC2VKY DFPqtpCiM/9xzjW7ivVR5Qh8LpDQlA9F3eJ7onKYDFEhQi23S/Kh8XxSfYsC1ALLvPuY Wsz2j50jccBzXVm7bvM1uQDjEWn9kK+TD2hF69WNyPoibxI3mUchgsx+UNM5PRA2dbP+ 1LXqr/nAJ2Z1ZHzidr/6WnpVXRhvbjFA3KfxLyEGpXPVE9GaaZ9DQEAMlTTnGl5Lg8OO 1LbaExoH34XPyLBoHWK6wSAVFh/e+h2XJ6yPtDCKZB/RT2ruBJmCtSQAgwW0cZjhwEQH uuuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:reply-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=hxiq/bleI/RiF1pIcTH/GOo4Dtqmo4x8aQIaJ+XOexY=; b=F1N8BjYxN6xiioJiVEfFLP15rOrgVryioZZqLGzg4LMnloeaksCEPZLCf5797gfKC1 EXCs635xkm2Ni2R9pPEK9Rx0CmyK901KUS32yRVbVFwTXWKytW1exOURHv7h0kjt084d eH2qyrTJBBh2SMbqgjaz7e8AZoDYBRxDuoNs87Ks0CwY/hVN8pPUgntVs6JLYY1QF5zC pWXRsCM6udHhsiGZC0kMyCKGlbCbdwTFqws/prttiAbi7XnJ6mF9EyE/7IUICYTwgRES AK4bFfJFL38XbJWQMS+0it9qYULYOVgp4/0dw/aO0N4aiLLQB9xkZCam9sEWPiIcQPSU ttIg== X-Gm-Message-State: AElRT7GdBvlmaTQlaYVDkmwPzBQLl0cgwvZQKSNxK7ABkXJhpGpl9Meh EuYyx0AL5Pd7TKOg1sGR1XU= X-Received: by 10.98.86.16 with SMTP id k16mr2310087pfb.149.1522228447230; Wed, 28 Mar 2018 02:14:07 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id y15sm6539771pfb.37.2018.03.28.02.14.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 02:14:06 -0700 (PDT) Date: Wed, 28 Mar 2018 17:13:57 +0800 From: Wei Yang To: Jia He Cc: Andrew Morton , Michal Hocko , Catalin Marinas , Mel Gorman , Will Deacon , Mark Rutland , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Pavel Tatashin , Daniel Jordan , AKASHI Takahiro , Gioh Kim , Steven Sistare , Daniel Vacek , Eugeniu Rosca , Vlastimil Babka , linux-kernel@vger.kernel.org, linux-mm@kvack.org, James Morse , Ard Biesheuvel , Steve Capper , x86@kernel.org, Greg Kroah-Hartman , Kate Stewart , Philippe Ombredanne , Johannes Weiner , Kemi Wang , Petr Tesarik , YASUAKI ISHIMATSU , Andrey Ryabinin , Nikolay Borisov , Jia He Subject: Re: [PATCH v2 1/5] mm: page_alloc: remain memblock_next_valid_pfn() when CONFIG_HAVE_ARCH_PFN_VALID is enable Message-ID: <20180328091357.GA97260@WeideMacBook-Pro.local> Reply-To: Wei Yang References: <1521894282-6454-1-git-send-email-hejianet@gmail.com> <1521894282-6454-2-git-send-email-hejianet@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1521894282-6454-2-git-send-email-hejianet@gmail.com> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Mar 24, 2018 at 05:24:38AM -0700, Jia He wrote: >Commit b92df1de5d28 ("mm: page_alloc: skip over regions of invalid pfns >where possible") optimized the loop in memmap_init_zone(). But it causes >possible panic bug. So Daniel Vacek reverted it later. > Why this has a bug? Do you have some link about it? If the audience could know the potential risk, it would be helpful to review the code and decide whether to take it back. >But memblock_next_valid_pfn is valid when CONFIG_HAVE_ARCH_PFN_VALID is >enabled. And as verified by Eugeniu Rosca, arm can benifit from this >commit. So remain the memblock_next_valid_pfn. > >Signed-off-by: Jia He >--- > include/linux/memblock.h | 4 ++++ > mm/memblock.c | 29 +++++++++++++++++++++++++++++ > mm/page_alloc.c | 11 ++++++++++- > 3 files changed, 43 insertions(+), 1 deletion(-) > >diff --git a/include/linux/memblock.h b/include/linux/memblock.h >index 0257aee..efbbe4b 100644 >--- a/include/linux/memblock.h >+++ b/include/linux/memblock.h >@@ -203,6 +203,10 @@ void __next_mem_pfn_range(int *idx, int nid, unsigned long *out_start_pfn, > i >= 0; __next_mem_pfn_range(&i, nid, p_start, p_end, p_nid)) > #endif /* CONFIG_HAVE_MEMBLOCK_NODE_MAP */ > >+#ifdef CONFIG_HAVE_ARCH_PFN_VALID >+unsigned long memblock_next_valid_pfn(unsigned long pfn); >+#endif >+ > /** > * for_each_free_mem_range - iterate through free memblock areas > * @i: u64 used as loop variable >diff --git a/mm/memblock.c b/mm/memblock.c >index ba7c878..bea5a9c 100644 >--- a/mm/memblock.c >+++ b/mm/memblock.c >@@ -1102,6 +1102,35 @@ void __init_memblock __next_mem_pfn_range(int *idx, int nid, > *out_nid = r->nid; > } > >+#ifdef CONFIG_HAVE_ARCH_PFN_VALID >+unsigned long __init_memblock memblock_next_valid_pfn(unsigned long pfn) >+{ >+ struct memblock_type *type = &memblock.memory; >+ unsigned int right = type->cnt; >+ unsigned int mid, left = 0; >+ phys_addr_t addr = PFN_PHYS(++pfn); >+ >+ do { >+ mid = (right + left) / 2; >+ >+ if (addr < type->regions[mid].base) >+ right = mid; >+ else if (addr >= (type->regions[mid].base + >+ type->regions[mid].size)) >+ left = mid + 1; >+ else { >+ /* addr is within the region, so pfn is valid */ >+ return pfn; >+ } >+ } while (left < right); >+ >+ if (right == type->cnt) >+ return -1UL; >+ else >+ return PHYS_PFN(type->regions[right].base); >+} >+#endif /*CONFIG_HAVE_ARCH_PFN_VALID*/ >+ > /** > * memblock_set_node - set node ID on memblock regions > * @base: base of area to set node ID for >diff --git a/mm/page_alloc.c b/mm/page_alloc.c >index c19f5ac..2a967f7 100644 >--- a/mm/page_alloc.c >+++ b/mm/page_alloc.c >@@ -5483,8 +5483,17 @@ void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone, > if (context != MEMMAP_EARLY) > goto not_early; > >- if (!early_pfn_valid(pfn)) >+ if (!early_pfn_valid(pfn)) { >+#if (defined CONFIG_HAVE_MEMBLOCK) && (defined CONFIG_HAVE_ARCH_PFN_VALID) In commit b92df1de5d28, it use CONFIG_HAVE_MEMBLOCK_NODE_MAP. Not get the point of your change. >+ /* >+ * 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. >+ */ >+ pfn = memblock_next_valid_pfn(pfn) - 1; >+#endif > continue; >+ } > if (!early_pfn_in_nid(pfn, nid)) > continue; > if (!update_defer_init(pgdat, pfn, end_pfn, &nr_initialised)) >-- >2.7.4 -- Wei Yang Help you, Help me