From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl0-f72.google.com (mail-pl0-f72.google.com [209.85.160.72]) by kanga.kvack.org (Postfix) with ESMTP id 756946B0008 for ; Mon, 2 Apr 2018 20:14:10 -0400 (EDT) Received: by mail-pl0-f72.google.com with SMTP id q12-v6so5028329plr.17 for ; Mon, 02 Apr 2018 17:14:10 -0700 (PDT) Received: from mail-sor-f65.google.com (mail-sor-f65.google.com. [209.85.220.65]) by mx.google.com with SMTPS id g15sor376823pgu.353.2018.04.02.17.14.09 for (Google Transport Security); Mon, 02 Apr 2018 17:14:09 -0700 (PDT) Date: Tue, 3 Apr 2018 08:14:01 +0800 From: Wei Yang Subject: Re: [PATCH v3 1/5] mm: page_alloc: remain memblock_next_valid_pfn() when CONFIG_HAVE_ARCH_PFN_VALID is enable Message-ID: <20180403001401.GA45531@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> <20180328091800.GB97260@WeideMacBook-Pro.local> <20180402081233.GA38180@WeideMacBook-Pro.local> <7288ce7c-7535-a5a1-7c7c-18456e431648@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7288ce7c-7535-a5a1-7c7c-18456e431648@gmail.com> Sender: owner-linux-mm@kvack.org List-ID: To: Jia He Cc: Wei Yang , 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 On Mon, Apr 02, 2018 at 05:17:35PM +0800, Jia He wrote: > > >On 4/2/2018 4:12 PM, Wei Yang Wrote: >> On Wed, Mar 28, 2018 at 05:49:23PM +0800, Jia He wrote: >> > >> > On 3/28/2018 5:18 PM, Wei Yang Wrote: >> > > 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. >> > Hi Wei >> > Paul firstly submit a commit b92df1de5 to improve the loop in >> > memmap_init_zone. >> > And Daniel tried to fix a bug_on panic issue on X86 in commit 864b75f9d6b >> > because >> > there is evidence that this bug_on was caused by b92df1de5 [1]. >> > >> > But things didn't get better, 864b75f9d6b caused booting hang issue on >> > arm{64} [2] >> > So maintainer decided to reverted both b92df1de5 and 864b75f9d6b >> > >> > [1] https://patchwork.kernel.org/patch/10251145/ >> > [2] https://lkml.org/lkml/2018/3/14/469 >> I took some time to look into the discussion, while the root cause seems not >> clear now? >> >Frankly speaking, to me the root cause of that bug_on is not completedly >clear :-) Daniel ever gave me some hints as followed, but currently I have >no x86 platform to understand the details. > >"On arm and arm64, memblock is used by default. But generic version of >pfn_valid() is based on mem sections and memblock_next_valid_pfn() >does not always return the next valid one but skips more resulting in >some valid frames to be skipped (as if they were invalid). And that's >why kernel was eventually crashing on some !arm machines." > This means a system with memblock is safe to use this function? As I know, mem_section is based on memblock, so in which case memblock_next_valid_pfn() skips a valid pfn? A little confused. >-- >Cheers, >Jia -- Wei Yang Help you, Help me