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 69F5BC432C3 for ; Wed, 27 Nov 2019 14:28:29 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 24BFD20674 for ; Wed, 27 Nov 2019 14:28:29 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lca.pw header.i=@lca.pw header.b="AYRYHFNR" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 24BFD20674 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 B03C76B04A3; Wed, 27 Nov 2019 09:28:28 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id AB4BE6B04A6; Wed, 27 Nov 2019 09:28:28 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9A45B6B04A7; Wed, 27 Nov 2019 09:28:28 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0173.hostedemail.com [216.40.44.173]) by kanga.kvack.org (Postfix) with ESMTP id 82C4F6B04A3 for ; Wed, 27 Nov 2019 09:28:28 -0500 (EST) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with SMTP id 4AE632C33 for ; Wed, 27 Nov 2019 14:28:28 +0000 (UTC) X-FDA: 76202287896.08.fog27_841d6ef14da2c X-HE-Tag: fog27_841d6ef14da2c X-Filterd-Recvd-Size: 5041 Received: from mail-qv1-f68.google.com (mail-qv1-f68.google.com [209.85.219.68]) by imf05.hostedemail.com (Postfix) with ESMTP for ; Wed, 27 Nov 2019 14:28:27 +0000 (UTC) Received: by mail-qv1-f68.google.com with SMTP id b18so476121qvy.3 for ; Wed, 27 Nov 2019 06:28:27 -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=YXJyFojL5ILMP5BafQm63d1ZU24BMnJVSHUVAXm/Y/M=; b=AYRYHFNRoqN9XOfry7ok5a3KfOuq5GQadTCdwcXgwCSm8XDZKvmKdO7xTcPzW31Sac BhapxI7RbAkvWm5KCzvMhqUVl1t018/08PfC91o/FaCmootVqq0LZCPIMbw/YRgEkFpO UZzvICkEU3Sn+nLAxvHxPxY58kubetYoz8oI7572e81V0l9oOY4WG1Evsist7AFEBSne b7+2hmA4pRu3d6dmZvojpkeYeS6JzFzHVMmLxVLrQdyFobobWVCsHSwGkLHClPu2h5Rg tI6RCk7FUlzNwI6m/OQsl49edPkuXrdUA+/uKCkeZRSHDuvGpPPooo5ann6RvrfRnUU6 8ZMA== 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=YXJyFojL5ILMP5BafQm63d1ZU24BMnJVSHUVAXm/Y/M=; b=LBUet0epGIGK5lNmCzKfDSYdPYJ6+ELoJP6tn6s3lfHrXpi7TzFz6JCIshqn9IvY6p 8MAP0aqzj0bbosrpJ9Ri7gBk/u68znuuQF3owHj+Y6D5w3KgFwcj65vUCPt2YspY1DBB 4+HDpn81zCYBHtDfa38/r0+nmBn1loPdRd8FVOa/PEw36eNl2UWrPAfn7JkFMcn+BYRs KsS2xb/A38+oF8X9L9FA4F/CgeD8mIrxf0Io6D0fMe7e7zrjzwCplNnnrx0QTww4dxIS XvOk61FLkZrMeRJMICneBWDkqYxdP+mRHhC50BMNoFJ05ej3ejCaZ2MM1Z72yhd3Swyy o8Fg== X-Gm-Message-State: APjAAAUvkj4VW5SmKoEbx6VrGh1+maKieBAZjXKr6cJeWt5/F51zXzaI MdRBDCTm5YhlwYlPdEJjIXN0RA== X-Google-Smtp-Source: APXvYqz2Ui2ZASIpzYk8sWIujMevvy16PyYQn5bV3W5PRHDdj3kj/kJnOxc0vV32oUEQOvh5vg7fkg== X-Received: by 2002:a0c:b062:: with SMTP id l31mr5224250qvc.43.1574864907036; Wed, 27 Nov 2019 06:28:27 -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 w13sm6911241qka.136.2019.11.27.06.28.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Nov 2019 06:28:26 -0800 (PST) Content-Type: text/plain; charset=us-ascii 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: <20191127141340.GA26807@dhcp22.suse.cz> Date: Wed, 27 Nov 2019 09:28:25 -0500 Cc: Kefeng Wang , linux-mm@kvack.org, Andrew Morton , Vlastimil Babka Content-Transfer-Encoding: quoted-printable Message-Id: 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: Michal Hocko 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:13 AM, Michal Hocko wrote: >=20 > 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. Indeed. Too many times people are only able to reproduce the issues on old kernels but insist to forward-fix the mainline as well which only = bring unstable there.=