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.3 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 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 8922BC433E0 for ; Thu, 4 Mar 2021 03:43:27 +0000 (UTC) Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3143364EEE for ; Thu, 4 Mar 2021 03:43:27 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3143364EEE Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=desiato.20200630; h=Sender:Content-Transfer-Encoding :Content-Type:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=/N21ytR1bdX2GmbY4YyVAx9Jy/SpQ87J5pQMOTNffXc=; b=qLtYG3/H7onddA1Hn5ziwPlG8 lIPD52jHU5C2jszxih9pN/Yo7fxM3+xgL0913aU0hlj5+9FpUm6xemI2po6cb027X6enIiC/IXcVr VvCLVf/VscNEmGE3n884EWj8i6oUJC3gX4c41A5gyoUizmwwr5dLZqe+qK4D7HUeDNBPWk0+qcqGh gsJUmro2BFrpaG/CM5td9t29IbhjtZdMkuxU8hj2erd6wn7pfuTPSBs+0wpfA36ctoCewX+BSKWV9 I18p9siu9YNlxR2YviUHP8ZJJJc+iFH8kO5bK75RpFcHSPkAth3yEPKy5uJupUJw/e+KLJWjyluBq wmBtbWn5A==; Received: from localhost ([::1] helo=desiato.infradead.org) by desiato.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lHehw-007cLJ-Lx; Thu, 04 Mar 2021 03:31:25 +0000 Received: from casper.infradead.org ([2001:8b0:10b:1236::1]) by desiato.infradead.org with esmtps (Exim 4.94 #2 (Red Hat Linux)) id 1lHehk-007cIa-2Y for linux-arm-kernel@desiato.infradead.org; Thu, 04 Mar 2021 03:31:17 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description; bh=43j/aC/HKwvxX2sTFx9yLKcLgKPEaFTk3lKwOtXgD5w=; b=i7FdfDYqhjRHNqhkuusVGGIOLo M4LOl4Lf1qtzP9aw97OkwYbTp9ksZpXLPLkwofFlX93VNBWIRwMgNnbAyZhAYhgi7MDFphe4/c5V9 6e8ReDI8Q+z0+vRJ3HuahvBB9mCBhEYEPD56p9q2RBByE6sqyClA1/M343s8Y8DAdy7j25tJqk/7C DWNiidPDb8x0YGqlzT1pu2FGFiXVPtSLwhte9zSgoEhj4aRNBxOOTP5fiwznihWSdneWu60IF3YBO KKxJvB7Zt8heS6K+0oNxogx8U/8eXbsJj8u2cIa/7iG+dclu0Eo0CnpRQydQs5ULLOM/TfTDDGtS1 Fy2eZE6Q==; Received: from foss.arm.com ([217.140.110.172]) by casper.infradead.org with esmtp (Exim 4.94 #2 (Red Hat Linux)) id 1lHehe-005KLN-8S for linux-arm-kernel@lists.infradead.org; Thu, 04 Mar 2021 03:31:08 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 8C52331B; Wed, 3 Mar 2021 19:30:53 -0800 (PST) Received: from [192.168.0.130] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 3C3EF3F73B; Wed, 3 Mar 2021 19:30:48 -0800 (PST) Subject: Re: [PATCH V2 1/2] arm64/mm: Fix pfn_valid() for ZONE_DEVICE based memory To: Will Deacon , Catalin Marinas Cc: David Hildenbrand , Mark Rutland , linux-kernel@vger.kernel.org, Mike Rapoport , linux-mm@kvack.org, =?UTF-8?B?SsOpcsO0bWUgR2xpc3Nl?= , James Morse , Dan Williams , Robin Murphy , Ard Biesheuvel , linux-arm-kernel@lists.infradead.org References: <20210202123524.GB16868@willie-the-truck> <20210202125152.GC16868@willie-the-truck> <4d8f5156-8628-5531-1485-322ad92aa15c@redhat.com> <0e649f28-4d54-319d-f876-8a93870cda7f@arm.com> <20210205185552.GA23216@willie-the-truck> <20210211115354.GB29894@willie-the-truck> <23e5eb93-a39c-c68e-eac1-c5ccf9036079@arm.com> <20210303190428.GB24035@arm.com> <20210303212406.GB20055@willie-the-truck> From: Anshuman Khandual Message-ID: Date: Thu, 4 Mar 2021 09:01:22 +0530 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20210303212406.GB20055@willie-the-truck> Content-Language: en-US X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20210304_033108_244618_A8EC00E3 X-CRM114-Status: GOOD ( 20.34 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On 3/4/21 2:54 AM, Will Deacon wrote: > On Wed, Mar 03, 2021 at 07:04:33PM +0000, Catalin Marinas wrote: >> On Thu, Feb 11, 2021 at 01:35:56PM +0100, David Hildenbrand wrote: >>> On 11.02.21 13:10, Anshuman Khandual wrote: >>>> On 2/11/21 5:23 PM, Will Deacon wrote: >>>>> ... and dropped. These patches appear to be responsible for a boot >>>>> regression reported by CKI: >>>> >>>> Ahh, boot regression ? These patches only change the behaviour >>>> for non boot memory only. >>>> >>>>> https://lore.kernel.org/r/cki.8D1CB60FEC.K6NJMEFQPV@redhat.com >>>> >>>> Will look into the logs and see if there is something pointing to >>>> the problem. >>> >>> It's strange. One thing I can imagine is a mis-detection of early sections. >>> However, I don't see that happening: >>> >>> In sparse_init_nid(), we: >>> 1. Initialize the memmap >>> 2. Set SECTION_IS_EARLY | SECTION_HAS_MEM_MAP via >>> sparse_init_one_section() >>> >>> Only hotplugged sections (DIMMs, dax/kmem) set SECTION_HAS_MEM_MAP without >>> SECTION_IS_EARLY - which is correct, because these are not early. >>> >>> So once we know that we have valid_section() -- SECTION_HAS_MEM_MAP is set >>> -- early_section() should be correct. >>> >>> Even if someone would be doing a pfn_valid() after >>> memblocks_present()->memory_present() but before >>> sparse_init_nid(), we should be fine (!valid_section() -> return 0). >> >> I couldn't figure out how this could fail with Anshuman's patches. >> Will's suspicion is that some invalid/null pointer gets dereferenced >> before being initialised but the only case I see is somewhere in >> pfn_section_valid() (ms->usage) if valid_section() && !early_section(). >> >> Assuming that we do get a valid_section(ms) && !early_section(ms), is >> there a case where ms->usage is not initialised? I guess races with >> section_deactivate() are not possible this early. >> >> Another situation could be that pfn_valid() returns true when no memory >> is mapped for that pfn. > > The case I wondered about was __pfn_to_section() with a bogus pfn, since > with patch 2/2 we call that *before* checking that pfn_to_section_nr() is > sane. Right, that is problematic. __pfn_to_section() should not be called without first validating pfn_to_section_nr(), as it could cause out-of-bound access on mem_section buffer. Will fix that order but as there is no test scenario which is definitive for this reported regression, how should we ensure that it fixes the problem ? _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel