From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 261C6C432C0 for ; Wed, 27 Nov 2019 15:09:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id D9C6220674 for ; Wed, 27 Nov 2019 15:09:34 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="HKWuEKhn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D9C6220674 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=lca.pw Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 761266B04B3; Wed, 27 Nov 2019 10:09:34 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 712536B04B4; Wed, 27 Nov 2019 10:09:34 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6019B6B04B5; Wed, 27 Nov 2019 10:09:34 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 464656B04B3 for ; Wed, 27 Nov 2019 10:09:34 -0500 (EST) Received: from smtpin04.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with SMTP id F3733181AEF1D for ; Wed, 27 Nov 2019 15:09:33 +0000 (UTC) X-FDA: 76202391426.04.mist28_36550ad39991a X-HE-Tag: mist28_36550ad39991a X-Filterd-Recvd-Size: 6062 Received: from mail-qt1-f194.google.com (mail-qt1-f194.google.com [209.85.160.194]) by imf17.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 Nov 2019 15:09:33 +0000 (UTC) Received: by mail-qt1-f194.google.com with SMTP id 14so25667186qtf.5 for ; Wed, 27 Nov 2019 07:09:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lca.pw; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FdY336tB+0Q/3e0KnaJP+1OGPTFzaTxuyA2LfUs0d1E=; b=HKWuEKhnzqLkKbJM+SDzuYdKPdkbLp5eLeRK9F/RwhZFYavZcvp56Cen4x4dqd/+pw xbIv3UtNCs5LZA+6O7cmVsIAOc3FM6vKvYU9i1WdsXaODoiSFkGT2YztEqXh74xLJWdC Ytc822wtUPTERZBw2hb5QyMjXh8PT6Z/QobKXgjS0NwcK6OxCPpW7roaZCaRnfVxqOU8 /3LcrX6fR45Z1gUeOygsS7WjdX+9i+tA0iFg8UdT5VQYjlRLWGMi48Jk6/BwKgxN/uoN c1/vtgPYw3x+X9QPDzEgSmxf8f4qtFpe3zv3/xv5m8gQdWpEGifKfSpqhpmddrxe709q 6yNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FdY336tB+0Q/3e0KnaJP+1OGPTFzaTxuyA2LfUs0d1E=; b=Ghq1/KbVVLYopoel5QNimKgeH2VorE7nKzobpx4yXyEpz8tMRYn+MsCLdhyGI1ItvA OYKw77QXETRA0mZXnd1Csr5k8lXWVAkf+goQZKSOrYKqaKOSCX01tN7ZCt7HScAQ7s8/ 015P5f5KAHRfKxQWZSfwh8pBOidheNIbJHU0c6SDlRGCApQausUOY8MkOSgi7w2Pt5/N ZqRrFx2rY4N+TGjHhQSdAyntbnVr1iEuLZ8JpAmImhYVIH+z/JDhm3xJeSu1v8oXzQtZ JkxYZhyAS+A7kuL9jQE53SsDgfP+zNuzyct8l04uT3T+5+M24/d21ivzggLI5fyYGGW3 2fXA== X-Gm-Message-State: APjAAAVA3J+QA19ACr5pgYYy9quypyUFAgBm9Ys/WZpNPSVC+Ff5c3EU ZHXl5dPG3THaNNJLKCcDAkLO0w== X-Google-Smtp-Source: APXvYqzDaF+0olGA8Sm7DOwuJYY9rRS4t19A4NXIVjbwwOY53Yu2La8EBcCH0KtqE9vInG02yfJYjA== X-Received: by 2002:aed:20e5:: with SMTP id 92mr30195196qtb.294.1574867372291; Wed, 27 Nov 2019 07:09:32 -0800 (PST) Received: from [192.168.1.153] (pool-71-184-117-43.bstnma.fios.verizon.net. [71.184.117.43]) by smtp.gmail.com with ESMTPSA id f6sm6953966qkk.12.2019.11.27.07.09.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Nov 2019 07:09:31 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Subject: Re: [RFC PATCH] mm, page_alloc: avoid page_to_pfn() in move_freepages() From: Qian Cai In-Reply-To: Date: Wed, 27 Nov 2019 10:09:30 -0500 Cc: Michal Hocko , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka , Will Deacon , Catalin Marinas , Mark Rutland Content-Transfer-Encoding: quoted-printable Message-Id: <0F069AED-ACAB-45D0-BAE0-329EF4418EBD@lca.pw> References: <20191127102800.51526-1-wangkefeng.wang@huawei.com> <20191127114750.GP20912@dhcp22.suse.cz> <5d11a679-d822-1c41-8798-1dbb285d3bf6@huawei.com> <20191127141340.GA26807@dhcp22.suse.cz> To: Kefeng Wang X-Mailer: Apple Mail (2.3601.0.10) X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: > On Nov 27, 2019, at 9:39 AM, Kefeng Wang = wrote: >=20 >=20 >=20 > On 2019/11/27 22:13, Michal Hocko wrote: >> On Wed 27-11-19 21:13:00, Kefeng Wang wrote: >>>=20 >>>=20 >>> On 2019/11/27 19:47, Michal Hocko wrote: >>>> On Wed 27-11-19 18:28:00, Kefeng Wang wrote: >>>>> The start_pfn and end_pfn are already available in = move_freepages_block(), >>>>> pfn_valid_within() should validate pfn first before touching the = page, >>>>> or we might access an unitialized page with CONFIG_HOLES_IN_ZONE = configs. >>>>>=20 >>>>> Cc: Andrew Morton >>>>> Cc: Michal Hocko >>>>> Cc: Vlastimil Babka >>>>> Signed-off-by: Kefeng Wang >>>>> --- >>>>>=20 >>>>> Here is an oops in 4.4(arm64 enabled CONFIG_HOLES_IN_ZONE), >>>>=20 >>>> Is this reproducible with the current upstream kernel? There were = large >>>> changes in this aread since 4.4 >>>=20 >>> Our inner tester found this oops twice, but couldn't be reproduced = for now, >>> even in 4.4 kernel, still trying... >>>=20 >>> But the page_to_pfn() shouldn't be used in move_freepages(), right? = ; ) >>=20 >> Well, I do agree that going back and forth between page and pfn is = ugly. >> So this as a cleanup makes sense to me. But you are trying to fix a = bug >> and that bug should be explained. NULL ptr dereference sounds like a >> memmap is not allocated for the particular pfn and this is a bit >> unexpected even with holes, at least on x86, maybe arm64 allows that. >> But the changelog should be clear about all this rather than paper = over >> a deeper problem potentially. Please also make sure to involve arm64 >> people. >=20 > I'm still trying to reproduce it on 4.4 and 5.4, add Catalin, Will = Mark, > could you give some advice on it, thanks. >=20 > = https://lore.kernel.org/linux-mm/54064878-ea85-247a-3382-b96ddf97c667@huaw= ei.com/T/#m87c545730a0a00c45e042937593c59f6552d1246 >=20 > note: > We backport numa patches into 4.4, so the CONFIG_HOLES_IN_ZONE is = enabled. >=20 > # CONFIG_NUMA is not set > CONFIG_HOLES_IN_ZONE=3Dy >=20 > CONFIG_SPARSEMEM_MANUAL=3Dy > CONFIG_SPARSEMEM=3Dy > CONFIG_HAVE_MEMORY_PRESENT=3Dy > CONFIG_SPARSEMEM_EXTREME=3Dy > CONFIG_SPARSEMEM_VMEMMAP_ENABLE=3Dy > CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=3Dy > # CONFIG_SPARSEMEM_VMEMMAP is not set See the commit b13bc35193d9 (=E2=80=9Cmm/hotplug: invalid PFNs from = pfn_to_online_page()=E2=80=9D) where it lists a lot of code churn in that space that might indicate = there are many commits missing in your kernel.