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=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED, USER_AGENT_SANE_1 autolearn=ham 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 D92A9C432C3 for ; Wed, 27 Nov 2019 14:40:11 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A855020722 for ; Wed, 27 Nov 2019 14:40:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A855020722 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=huawei.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 41C266B04A7; Wed, 27 Nov 2019 09:40:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3CC886B04A8; Wed, 27 Nov 2019 09:40:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2BC046B04A9; Wed, 27 Nov 2019 09:40:11 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0153.hostedemail.com [216.40.44.153]) by kanga.kvack.org (Postfix) with ESMTP id 15A556B04A7 for ; Wed, 27 Nov 2019 09:40:11 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id A62888249980 for ; Wed, 27 Nov 2019 14:40:10 +0000 (UTC) X-FDA: 76202317380.30.shirt81_5895c67b5c534 X-HE-Tag: shirt81_5895c67b5c534 X-Filterd-Recvd-Size: 3737 Received: from huawei.com (szxga04-in.huawei.com [45.249.212.190]) by imf09.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 Nov 2019 14:40:08 +0000 (UTC) Received: from DGGEMS412-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id E82D049728E4FD03EA4A; Wed, 27 Nov 2019 22:40:00 +0800 (CST) Received: from [127.0.0.1] (10.133.217.137) by DGGEMS412-HUB.china.huawei.com (10.3.19.212) with Microsoft SMTP Server id 14.3.439.0; Wed, 27 Nov 2019 22:39:58 +0800 Subject: Re: [RFC PATCH] mm, page_alloc: avoid page_to_pfn() in move_freepages() To: Michal Hocko CC: , Andrew Morton , "Vlastimil Babka" , Will Deacon , Catalin Marinas , Mark Rutland 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> From: Kefeng Wang Message-ID: Date: Wed, 27 Nov 2019 22:39:56 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <20191127141340.GA26807@dhcp22.suse.cz> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [10.133.217.137] X-CFilter-Loop: Reflected 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 2019/11/27 22:13, Michal Hocko wrote: > On Wed 27-11-19 21:13:00, Kefeng Wang wrote: >> >> >> 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. >>>> >>>> Cc: Andrew Morton >>>> Cc: Michal Hocko >>>> Cc: Vlastimil Babka >>>> Signed-off-by: Kefeng Wang >>>> --- >>>> >>>> Here is an oops in 4.4(arm64 enabled CONFIG_HOLES_IN_ZONE), >>> >>> Is this reproducible with the current upstream kernel? There were large >>> changes in this aread since 4.4 >> >> Our inner tester found this oops twice, but couldn't be reproduced for now, >> even in 4.4 kernel, still trying... >> >> But the page_to_pfn() shouldn't be used in move_freepages(), right? ; ) > > 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. 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. https://lore.kernel.org/linux-mm/54064878-ea85-247a-3382-b96ddf97c667@huawei.com/T/#m87c545730a0a00c45e042937593c59f6552d1246 note: We backport numa patches into 4.4, so the CONFIG_HOLES_IN_ZONE is enabled. # CONFIG_NUMA is not set CONFIG_HOLES_IN_ZONE=y CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y # CONFIG_SPARSEMEM_VMEMMAP is not set >