Received: by 10.213.65.68 with SMTP id h4csp1373158imn; Wed, 14 Mar 2018 19:25:10 -0700 (PDT) X-Google-Smtp-Source: AG47ELsG8efhS0QwaYTARzUuTG3hiyOefU+liv95lfnRS/3fc8bkAsbWUFFBGAqKjuW7tyESN+3c X-Received: by 2002:a17:902:6082:: with SMTP id s2-v6mr6176458plj.307.1521080710009; Wed, 14 Mar 2018 19:25:10 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521080709; cv=none; d=google.com; s=arc-20160816; b=tIk9eZJdhSoaGwRAfzl2XkY4yUBAHSPFxfFsM7mESgfjRJX/I+tOdMbGvCTYrlbpwa dwujlZJNowHSCQDr1CxVIhjOaeMz2azsO+0y3IE/Cwqfy/qrvURAVjlyb8m0b0Q368Z1 G8bXDvQ3lykJHX+e+wPhjMmtmPsZNau8MQTkBjDmP2RPSjdWq5+LRVhU2UjhhTFjj9ZM DCkbCYleP9hLePcUbLlt3RClHJjf8tJWBpskkaa8FIoz+PL+ZDCVNB6/Y/0xFwv/QkoH kDvlM2pA5TLZnpj1wKY1hRSEwigDebO+Mnuv94TgNO2smijrjrDgt9QXiGzrrfilqaLM aqOg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :references:in-reply-to:mime-version:arc-authentication-results; bh=rJaveqPv0BHOo0gJ4vjZK2mpFRAZsR48geJ9/5KXR4w=; b=tRuPd+hZH88ZvP7sq+Nc8bbYHfurq50lEHfdtjs8/QcJ91SepYwuTw1HZHYDqeK2u1 oj3RS/J/j2BiZOK3JUg7b8Ic1Q/Kf9Byj2pk0hE/LM4GrRD16cNIZ3Nudskhy4XxHGw7 04qbyaIPGoL8mbTFDPHFvtSBEVNHyg2Y7Pnmf3A5as9G26EjM/89B6RibSv18NpimRy/ dUKRzwyJytUhmk8SB2ZGH9TAASxC1PFmABRND7EsTWdBX+vZHJErcu6oMM1C8BaD0FXD WynoBgatpuNzKdiwcNYFXZPk90aJt45TBlx3Zj/q9VgeP9NyLCE0wLUPfCyUTkh/MmJW k7vQ== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x190si2791671pgx.159.2018.03.14.19.24.54; Wed, 14 Mar 2018 19:25:09 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751595AbeCOCYB (ORCPT + 99 others); Wed, 14 Mar 2018 22:24:01 -0400 Received: from mail-oi0-f66.google.com ([209.85.218.66]:37883 "EHLO mail-oi0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751449AbeCOCYA (ORCPT ); Wed, 14 Mar 2018 22:24:00 -0400 Received: by mail-oi0-f66.google.com with SMTP id f186so4459715oig.4 for ; Wed, 14 Mar 2018 19:24:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rJaveqPv0BHOo0gJ4vjZK2mpFRAZsR48geJ9/5KXR4w=; b=raDnac+pRZ/oC/HPCZZe7ya3DgAQ+RNrpgmuHRa9tTPrifV8y698EWwnMq2RJel0Pc H2XNGNc0ANVeXhKpwn6JgfyMkOeyZSvO8aLdSZ3ekQO/KaDkSlOX6jAf4Ndc3qKI5c6M yG0nbVpOAMqy5NK56LPU10oK3yM15FAt+JtLl05mvcFn4E/YZCrtY6/Fg3kGzzvMayA5 wZGRAK55n00BTXGQ80q76wtz4DwqfnEldaYfMNrhDG1bGFZWNk7u3CHyYFy/G7jXlgwM icxFdQ0r2AbLWXv1aIrwfLdZ5x1DQMEObWDzwaWqmZcZ1axDkZwSvNvK/xTRGIjZ76tL Ufcw== X-Gm-Message-State: AElRT7HOdcBAAwyl8RqIaxiqMyNvMvrKtwo9vXsxo1qPwb+acn/nmdmc Xv2Hbunwy33pDxO34/GczBuBPauDEGpL0iP3fcNIDpIfszs= X-Received: by 10.202.236.130 with SMTP id k124mr4058321oih.33.1521080639715; Wed, 14 Mar 2018 19:23:59 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a9d:39f6:0:0:0:0:0 with HTTP; Wed, 14 Mar 2018 19:23:59 -0700 (PDT) In-Reply-To: <20180314192937.12888-1-ard.biesheuvel@linaro.org> References: <20180314192937.12888-1-ard.biesheuvel@linaro.org> From: Daniel Vacek Date: Thu, 15 Mar 2018 03:23:59 +0100 Message-ID: Subject: Re: [PATCH v2] Revert "mm/page_alloc: fix memmap_init_zone pageblock alignment" To: Ard Biesheuvel Cc: linux-arm-kernel@lists.infradead.org, open list , mark.rutland@arm.com, will.deacon@arm.com, catalin.marinas@arm.com, marc.zyngier@arm.com, Mel Gorman , Michal Hocko , Paul Burton , Pavel Tatashin , Vlastimil Babka , Andrew Morton , Linus Torvalds Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 14, 2018 at 8:29 PM, Ard Biesheuvel wrote: > This reverts commit 864b75f9d6b0100bb24fdd9a20d156e7cda9b5ae. > > Commit 864b75f9d6b0 ("mm/page_alloc: fix memmap_init_zone pageblock > alignment") modified the logic in memmap_init_zone() to initialize > struct pages associated with invalid PFNs, to appease a VM_BUG_ON() > in move_freepages(), which is redundant by its own admission, and > dereferences struct page fields to obtain the zone without checking > whether the struct pages in question are valid to begin with. > > Commit 864b75f9d6b0 only makes it worse, since the rounding it does > may cause pfn assume the same value it had in a prior iteration of > the loop, resulting in an infinite loop and a hang very early in the > boot. Also, since it doesn't perform the same rounding on start_pfn > itself but only on intermediate values following an invalid PFN, we > may still hit the same VM_BUG_ON() as before. > > So instead, let's fix this at the core, and ensure that the BUG > check doesn't dereference struct page fields of invalid pages. > > 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 | 13 +++++-------- > 1 file changed, 5 insertions(+), 8 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 3d974cb2a1a1..635d7dd29d7f 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -1910,7 +1910,9 @@ static int move_freepages(struct zone *zone, > * Remove at a later date when no bug reports exist related to > * grouping pages by mobility > */ > - VM_BUG_ON(page_zone(start_page) != page_zone(end_page)); > + VM_BUG_ON(pfn_valid(page_to_pfn(start_page)) && > + pfn_valid(page_to_pfn(end_page)) && > + page_zone(start_page) != page_zone(end_page)); Hi, I am on vacation this week and I didn't have a chance to test this yet but I am not sure this is correct. Generic pfn_valid() unlike the arm{,64} arch specific versions returns true for all pfns in a section if there is at least some memory mapped in that section. So I doubt this prevents the crash I was targeting. I believe pfn_valid() does not change a thing here :( ------------------------ include/linux/mmzone.h: pfn_valid(pfn) valid_section(__nr_to_section(pfn_to_section_nr(pfn))) return (section && (section->section_mem_map & SECTION_HAS_MEM_MAP)) arch/arm64/mm/init.c: #ifdef CONFIG_HAVE_ARCH_PFN_VALID int pfn_valid(unsigned long pfn) { return memblock_is_map_memory(pfn << PAGE_SHIFT); } EXPORT_SYMBOL(pfn_valid); #endif ------------------------ Also I already sent a fix to Andrew yesterday which was reported to fix the loop. Moreover, you also reported this: > 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 I am wondering how come pfn_valid(0xfebf0) returns false here. Should it be true or do I miss something? --nX