Received: by 10.213.65.68 with SMTP id h4csp224961imn; Wed, 28 Mar 2018 02:19:49 -0700 (PDT) X-Google-Smtp-Source: AIpwx48jzG3A7KQz+z7/VE/9CnMwIUscltW4vZwAvP/jObmbx97NIPnoxnngqw1V0tqzz1lAdgyw X-Received: by 2002:a17:902:684d:: with SMTP id f13-v6mr2935583pln.230.1522228789535; Wed, 28 Mar 2018 02:19:49 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522228789; cv=none; d=google.com; s=arc-20160816; b=JpS+wsun51rtIzkyEL5PM/1M6Ksj5ZOpfnZ8+uvvFJ3AtCfdC7ECvFd4kZTtmA7WLG LNc/+P8e3A6B/UngnlSLsVF67roFjy1RYkawdVJS8Xyvy4Sw4pKJzTwfIIQdKcphRWwQ c/2ZSUEl7H3ZAIbvoyWpkfykxrENw8NsWDa9Fua80926PxEu1Ez4ZEHxODwDUqrU3XnD /KBMgLfTfQcPxQCLJb/vXo8SarPsuCsxMuzDPwsCCyxxtkX2ORPnmXdfEMdFLVVtnDyW 22JB3s40WtpsXFgw0nuYlxNLRAWaxHOhXzBnbINxOYxd0+lHZVNISN6vmHjgH4ONtByF u+1A== 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=xOs3wDQbjD8D9N7IXi9Gu+T0tjxN8DyDbnC6caruwww=; b=ujsd4japS7OzM9SLBlPn7Pw1Q/r5vnO7LKoSEWlc2z5DcGnXr28HTlOF1g9PTQp39o l5O+mDwARA5KnHa84vF0mHgaHl/w4SnMcQwISom5clIFcrTDVIHBcTQOwxGc2n/aSlnt 0aD//yQTC1oqfvrECi2xw5pxpwQAgB/EMo/ophcaVoktyFKqmTRovr5QG2YSSDy9LhqD 1cTbTFZl89axsX/zxY5ReoGAx7JVu94iDQGLNylfdH+kdmwWXpiGV9k55mfuWllEX49U OChFhG8yPWl45fq+OsHU+gWd10ZZrwaqETgv//+4jXH5grYDiFqw/3S7fckibKC/CAqC Qzkg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=XQB08uU7; 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 m65si2515515pfc.9.2018.03.28.02.19.35; Wed, 28 Mar 2018 02:19:49 -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=XQB08uU7; 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 S1752547AbeC1JSL (ORCPT + 99 others); Wed, 28 Mar 2018 05:18:11 -0400 Received: from mail-pl0-f66.google.com ([209.85.160.66]:37038 "EHLO mail-pl0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752169AbeC1JSI (ORCPT ); Wed, 28 Mar 2018 05:18:08 -0400 Received: by mail-pl0-f66.google.com with SMTP id v7-v6so1214790plo.4 for ; Wed, 28 Mar 2018 02:18:08 -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=xOs3wDQbjD8D9N7IXi9Gu+T0tjxN8DyDbnC6caruwww=; b=XQB08uU7PIrgI3OecZ5JPMJUVgkwE69DlxAmmcjl0om2sGVjFw8dNAuZIpGbGt7Maz wBPL8YERvX5s/6JN+9WNQaYO0dSfwL55TcltBcNm+Kcy0yh7b7gNqFNC+h//U8SEzug0 lpJktoezTrcSxjkhEDjD9a14ZlBF4N4sm8T4jam1wYKVZMPa85D8JaIzeI/r7P7b6cI3 hAJuAExUjxJpJlYMTUljQwrGeJoH2FDovCs97tfgIlq+gfYs2EkQV/GdEcw4SJAn1o8J TLyahAc386ocVGufk2sjyIMD6mqG0TyluRTFd2eoyhzgdBw2uJptQHB5aXtx+U/j2LMI D5sw== 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=xOs3wDQbjD8D9N7IXi9Gu+T0tjxN8DyDbnC6caruwww=; b=bazI9MoN2S9CVCVsOH2IpaKL9tU1EDxDj3aWvAPy6XxOHIBTFtrV94hmCEsPH/2o/C YwStoUqQTmc5foLVqac65ns0dsAcLl+wiMJtjjgAbv9Lmwfz2z0YyuHgfQ1meL/XJEBk Yic2wMPeiwvvHQUQfrfX6bkYqoN8C2Cnp1sKUiSga9FKJsIlLShfDIGljRIjmftAxEB1 36ZLIiwbEzSm4Ki+pFM3O6u2sgaxPpFntFFhuEBSEvJ7DIYFc9qa78q4S9BcOyhfX0V9 fTs4hJT9uiagN97GTkifvwygNm3pKU3HAR4PkLTwrgPbfGU0tyhmwIlredz7ptYtBG0H YWaA== X-Gm-Message-State: AElRT7E9uey1dXgubHa4eITjEVxk2vzimDT+c9pzskX2/PYj3THdRMA4 s/rJ7VzwtW9YLzYexY13DQY= X-Received: by 2002:a17:902:983:: with SMTP id 3-v6mr3046396pln.278.1522228688282; Wed, 28 Mar 2018 02:18:08 -0700 (PDT) Received: from localhost ([185.92.221.13]) by smtp.gmail.com with ESMTPSA id 29sm7974660pfj.40.2018.03.28.02.18.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Mar 2018 02:18:07 -0700 (PDT) Date: Wed, 28 Mar 2018 17:18:00 +0800 From: Wei Yang To: Jia He Cc: Andrew Morton , Michal Hocko , Catalin Marinas , Mel Gorman , Will Deacon , Mark Rutland , Ard Biesheuvel , 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 , 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 v3 1/5] mm: page_alloc: remain memblock_next_valid_pfn() when CONFIG_HAVE_ARCH_PFN_VALID is enable Message-ID: <20180328091800.GB97260@WeideMacBook-Pro.local> Reply-To: Wei Yang References: <1522033340-6575-1-git-send-email-hejianet@gmail.com> <1522033340-6575-2-git-send-email-hejianet@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1522033340-6575-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 Oops, I should reply this thread. Forget about the reply on another thread. On Sun, Mar 25, 2018 at 08:02:15PM -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 >enable. 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