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 D1364C432C0 for ; Wed, 27 Nov 2019 14:13:44 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7EB072068E for ; Wed, 27 Nov 2019 14:13:44 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7EB072068E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id DCD856B0491; Wed, 27 Nov 2019 09:13:43 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id D7E446B0492; Wed, 27 Nov 2019 09:13:43 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id C93F26B0493; Wed, 27 Nov 2019 09:13:43 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0238.hostedemail.com [216.40.44.238]) by kanga.kvack.org (Postfix) with ESMTP id B3DBD6B0491 for ; Wed, 27 Nov 2019 09:13:43 -0500 (EST) Received: from smtpin27.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with SMTP id 78685180AD815 for ; Wed, 27 Nov 2019 14:13:43 +0000 (UTC) X-FDA: 76202250726.27.box67_353ffaafae60 X-HE-Tag: box67_353ffaafae60 X-Filterd-Recvd-Size: 2625 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 Nov 2019 14:13:42 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id E543BBCFB; Wed, 27 Nov 2019 14:13:40 +0000 (UTC) Date: Wed, 27 Nov 2019 15:13:40 +0100 From: Michal Hocko To: Kefeng Wang Cc: linux-mm@kvack.org, Andrew Morton , Vlastimil Babka Subject: Re: [RFC PATCH] mm, page_alloc: avoid page_to_pfn() in move_freepages() Message-ID: <20191127141340.GA26807@dhcp22.suse.cz> References: <20191127102800.51526-1-wangkefeng.wang@huawei.com> <20191127114750.GP20912@dhcp22.suse.cz> <5d11a679-d822-1c41-8798-1dbb285d3bf6@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5d11a679-d822-1c41-8798-1dbb285d3bf6@huawei.com> User-Agent: Mutt/1.10.1 (2018-07-13) 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 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. -- Michal Hocko SUSE Labs