Received: by 10.213.65.68 with SMTP id h4csp1489003imn; Thu, 15 Mar 2018 00:38:34 -0700 (PDT) X-Google-Smtp-Source: AG47ELtCqN9ZcM27MFTeKvj+6xPNC79V4EMWQnLDDPYs/ZVEnUAmAuMp+GmX3FXdvf9k6tOKhUIA X-Received: by 10.98.77.194 with SMTP id a185mr6890887pfb.123.1521099514110; Thu, 15 Mar 2018 00:38:34 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521099514; cv=none; d=google.com; s=arc-20160816; b=YcglejYQGXgjM6T6YUQIY1eQFPoksYkS/EXojxqF4Z2SpenLJYXC7Lo5KXlyV159ua Ofus02WsCleREYorIv4aOhVoYHXkwSWngYC4WAWTco3TuU5k9dbMgarkQ/kiws63R+1G eUf27d5olp6smBxR3AchrUJNubveyX5tFIK7zLvHHbmzRIqPo4r2nJKSlJ4OdLsjkt7v GVoW1aIGjO08VRRubohzb7yMPJcJ7tgeBKURMsSPBxnYnT/8vtIP4YQxwwUpJ9/CcRmO 1Q3+ELtFq3g725fWJn7B0x+nF1A5RONLphKhiu5EN7xLVAQY+gURyqncc+ERTDByqbmz Jxtg== 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:dkim-signature :arc-authentication-results; bh=Q2oGJ96tSCsWVV7DzMtT12zdWnkrqUhmJgEDy4h0/Y8=; b=utYnGp28S26PaBBjZiyWJcc6/iXe5CgKQNHkK5l6+yL8mktSocM4HnqwssnXIb2Z5r 9qlLs24PLJgSss1N4X0EWkU0ANgsl2NMml0sAkhlW3JeAwh96xqpcTMGWqXk/bhug5pV GBJt24SguhuwL1SOVGeC2MNE27dKPcRZwVtsJfQmZaSEpspCyeBp/HQVhs1hE2xAyZkI rCfvBeKcFAN31/FjiIqj5UYMhFOEruO62/rXtVLZONa2u7KymsgJDP/wZOCX3MTe7Rvv 0RbsfUsxZeAM0PQLqxpiRFE1HWRPsfDzGwbpPyMz7WPs5zf0nyh2Ik7VowOfVn0v0VL0 Nm8A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=TmiXEE/N; 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=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u11si3088051pgo.695.2018.03.15.00.38.20; Thu, 15 Mar 2018 00:38:34 -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=@linaro.org header.s=google header.b=TmiXEE/N; 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=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751887AbeCOHhA (ORCPT + 99 others); Thu, 15 Mar 2018 03:37:00 -0400 Received: from mail-it0-f66.google.com ([209.85.214.66]:50263 "EHLO mail-it0-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750777AbeCOHg6 (ORCPT ); Thu, 15 Mar 2018 03:36:58 -0400 Received: by mail-it0-f66.google.com with SMTP id d13-v6so7881443itf.0 for ; Thu, 15 Mar 2018 00:36:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q2oGJ96tSCsWVV7DzMtT12zdWnkrqUhmJgEDy4h0/Y8=; b=TmiXEE/NVGskfoeBxKul1Mx+64JEoF1PDH4DIHGjfsvO/roSbLxuwA8ptAoduvz18X 4Mrr1c70rbd+5SdZijR0lFLANLwTljg+9VF33aTQgmDBG+EE9LfleB25h6o5H5pMPVcG AvqeqwIAosCN+3dw8vlQcQVg23FGEdx36xn94= 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=Q2oGJ96tSCsWVV7DzMtT12zdWnkrqUhmJgEDy4h0/Y8=; b=i6EaInmeuHbM5hF6U0tzG1W3vN3ThyjQrFFTeNREQfiqnCzLsycAJtgNOEJEMGeo/4 QIUa8Qo2C0u08RTqOG9mTfMprrobSZM+TfvGJ4jWYsXC8oI8BOh0nvmm7/nSUb+mIaSO QfBZsKjj0AAFjIXvzVt4UYc5YpjphQZjEQipWUjMMdEjMqZ4Ab7Ay8tTj/B3JqZ+1qlq JwDllbyP+lkRAQ9ohWWse4lO+PSIfkU3vTqeDLfd48O69SKwoj5Okq328Z+2SkdXcDuK cLq+LsXSns5zRqlo1wTUf/d3vOeNOzRddw2BQs4WzEgIgHSmw+uZxxnsoDS7Idx8QmBz aO2g== X-Gm-Message-State: AElRT7G+A6Y2dFQ7xIh7zsfY4Vf+UtAVyIGcC6DhdU6mkWnVh9LLh628 jVNzwYNpXxqEIc5+JZZkr+6rAaY3AyjonI8FieEZmw== X-Received: by 10.36.90.5 with SMTP id v5mr5142520ita.138.1521099417984; Thu, 15 Mar 2018 00:36:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.138.209 with HTTP; Thu, 15 Mar 2018 00:36:57 -0700 (PDT) In-Reply-To: References: <20180314192937.12888-1-ard.biesheuvel@linaro.org> From: Ard Biesheuvel Date: Thu, 15 Mar 2018 07:36:57 +0000 Message-ID: Subject: Re: [PATCH v2] Revert "mm/page_alloc: fix memmap_init_zone pageblock alignment" To: Daniel Vacek Cc: linux-arm-kernel , open list , Mark Rutland , Will Deacon , Catalin Marinas , Marc Zyngier , 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 15 March 2018 at 02:23, Daniel Vacek wrote: > 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 :( > If this is the case, memblock_next_valid_pfn() is broken since it skips valid PFNs, and we should be fixing that instead. > ------------------------ > 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