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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 44AA9E77188 for ; Fri, 3 Jan 2025 17:58:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id BB74D6B008A; Fri, 3 Jan 2025 12:58:58 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B67536B0093; Fri, 3 Jan 2025 12:58:58 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id A55F76B0098; Fri, 3 Jan 2025 12:58:58 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 873166B008A for ; Fri, 3 Jan 2025 12:58:58 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 0AB69120960 for ; Fri, 3 Jan 2025 17:58:58 +0000 (UTC) X-FDA: 82966899918.30.36F805F Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf18.hostedemail.com (Postfix) with ESMTP id C45DA1C0012 for ; Fri, 3 Jan 2025 17:58:32 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1735927101; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rSqNWSBaV4p1bQlMmFCc0ZsTCUtJFbgo6rfxh+KNAgM=; b=uc/P13xFJB20JpQN12LImS50rc8Xzxfl2V3Ldc2YdgPq3jN2/+N/uh+3B/WhhhaA5ODp4U PSxujlwqtofJEbfHtrsJIGWZfxCkRHtf9xVBtC94BRx/h6faxpW+YRJojJSwklH9EcjQB1 s5rP6zBAyUpzVPZJrGNkw3fxZiWYbdM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1735927101; a=rsa-sha256; cv=none; b=mFT204iw8bm7HsCDrxlVusUZa6xfV8LiBl/w0wxfrk8uMpBhtRhKhyx/kgAtvok0dWE49V 7XIazWZkl3mikU1+8pje8vCtlNR9Ri7k6fmUlYb8b5Fa3LQ/Ldv5HfkceNCqc7x+NFHTqm 7NZhciSDP0Dwy2RXU3ZSRrewrodgDJY= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=none; spf=pass (imf18.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 1ACD95C64E1; Fri, 3 Jan 2025 17:58:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id BC5D1C4CECE; Fri, 3 Jan 2025 17:58:52 +0000 (UTC) Date: Fri, 3 Jan 2025 17:58:50 +0000 From: Catalin Marinas To: Zhenhua Huang Cc: Anshuman Khandual , will@kernel.org, ardb@kernel.org, ryan.roberts@arm.com, mark.rutland@arm.com, joey.gouly@arm.com, dave.hansen@linux.intel.com, akpm@linux-foundation.org, chenfeiyang@loongson.cn, chenhuacai@kernel.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 2/2] arm64: mm: implement vmemmap_check_pmd for arm64 Message-ID: References: <20241209094227.1529977-1-quic_zhenhuah@quicinc.com> <20241209094227.1529977-3-quic_zhenhuah@quicinc.com> <39a85800-47c5-4529-906d-5a40e58ce136@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C45DA1C0012 X-Stat-Signature: d7n7g847oudjdcryqk9kdgeh94zh81ok X-Rspam-User: X-HE-Tag: 1735927112-435270 X-HE-Meta: U2FsdGVkX18ijv9jPTBo6W+mXeqJBBNrWayfbyQ25Iplbt3+VpIF+XGPqbGrNF53hxlZt5Z1WfRNT/KpAHU3T4ZAMTjGSv9Qr1smc5kk3L4Nz0LCvc/AUvTUdWmknwISNE4jhmRnE6x3qTkqmkq4hcEJ4bPtiuOPgqprKcmqUM25S74lkyd4Hw7MhBH7rcX5IZRMWltZtQ6vU7NvbVWV+jk1C8MPT83lDRhWgfF991/vglUbMh11vfigMHaaDC43EOHNXBuVpcFHgEJ79hOVXb9TQCTGBWewnugglx1/IAjAuitRxw+nPMsGxnpwVFNWj04mEzvTAm8oWCxZw3zOTehQNYQV67HXg+yKd01NmxF8K/y2Ez/AuuZ0/N/AqkL36ypUMd+rfrXmD8s4B01AAuKNh23UyktZe70QRqYb2zc3WVXJLqt10R+2ct/PUb2Hq4YPdZlJ3yGwxiXBdv84YaTUyzPPinEMOPqD5RE6g2d2QI5xq77K28cra+RsbnwWVNHg53VUDnPQaE95pZjLtsUw4irLw4FEH9mo1I8P6Ho6Tf3lYMo7iHH+G/n/m9HukX2eHeeMQrCNTFE36nEpxVUyRf1fBe7qf9I2MfeUZTGGQekKg/IqpvI/tAbvOm95xiNw1BHKpe2TqkCcbTqx9etVRk9LCW+vnKJzDb5PL6lcxWyyWf/h+RjRw1k6uze6nHWpyYcCs2Ftcg6MfzBLbh3XQSDKAUHtaSqUaT2px/EVkxfOsgmVSyE1x8RSRHTZ2yVcPwY+tI2Kt/0ekZhaPuoru4yGSKnVM6sZDYukGi7JuqqylU2lP1LKijIfM0aulu1mg60KqwnuryZ5gCJEUXzMGY8qwq/5OiBf7uk+liZWSH3RTIy9PIv8SKUJkW4iifa5E6FFLE2ehi1DOmBv6g+KW+oU8phXurP1JRHNSvVzAbyuZW3X3wUHtVhr5a5UsT2jW54sec46/n4Fglh rwSgxR7O /uIjVhKa9b1870Qy9rrIJjDnOmkg0vao+Tvqhf2b9FMhouRM7wpJrgN7Jn9Ch39rfdfMbL6Q0VSYW5+FtnEHPG5SZ6P5JkEb6tN9l2EkK3K3p/2kvClxiz24mLNqz6FiIV9ILpNjFeDZAdOJmys1nxAqw3meVWL0CPkxZnil6hGRcqf70TXpNOz23AMVzq/ZP+fCPMouknpAHlxIaf0qNueyzfH7tQgnIiDs2Pyy/QHsoZ3UuBdMC9Win7caMmikBlole/UgRqTDM/3bWsnLavrynZ4ypoFXpzOBBGw2oLTQGHDKZ8iGvJ+V1TKZwV0yi8xgRYu4+EFar+DLry2uQF3g2vddIeayNrWIYQl5NTKifbKzjXYanSYoCZTCZcG2pGiwV9BpVsTux1j1t+k7WbfGGtkv0rRT7j+Uv9q5SkvdjUiuyM8bar3/d++QI05+ODcEYuby2H6QriLie3CmBJjVa4R9EOtdiKpKj 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: List-Subscribe: List-Unsubscribe: On Fri, Jan 03, 2025 at 10:43:51AM +0800, Zhenhua Huang wrote: > On 2025/1/3 2:12, Catalin Marinas wrote: > > On Fri, Dec 27, 2024 at 08:27:18AM +0530, Anshuman Khandual wrote: > > > On 12/21/24 00:05, Catalin Marinas wrote: > > > > On Mon, Dec 09, 2024 at 05:42:27PM +0800, Zhenhua Huang wrote: > > > > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > > > > > index fd59ee44960e..41c7978a92be 100644 > > > > > --- a/arch/arm64/mm/mmu.c > > > > > +++ b/arch/arm64/mm/mmu.c > > > > > @@ -1169,7 +1169,8 @@ int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node, > > > > > unsigned long addr, unsigned long next) > > > > > { > > > > > vmemmap_verify((pte_t *)pmdp, node, addr, next); > > > > > - return 1; > > > > > + > > > > > + return pmd_sect(*pmdp); > > > > > > Please change this as pmd_sect(READ_ONCE(*pmdp)) instead. > > > > > > > > } > > > > > int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node, > > > > > > > > Don't we need this patch only if we implement the first one? Please fold > > > > it into the other patch. > > > > > > Seems like these patches might not be related. > > > > > > While creating huge page based vmemmap mapping during vmemmap_populate_hugepages(), > > > vmemmap_check_pmd() validates if a populated (i.e pmd_none) PMD already represents > > > a huge mapping and can be skipped there after. > > > > > > Current implementation for vmemmap_check_pmd() on arm64, unconditionally returns 1 > > > thus asserting that the given populated PMD entry is a huge one indeed, which will > > > be the case unless something is wrong. vmemmap_verify() only ensures that the node > > > where the pfn is allocated from is local. > > > > > > int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node, > > > unsigned long addr, unsigned long next) > > > { > > > vmemmap_verify((pte_t *)pmdp, node, addr, next); > > > return 1; > > > } > > > > > > However it does not really check the entry to be a section mapping which it should. > > > Returning pmd_sect(READ_ONCE(*pmdp)) is the right thing, which should have been the > > > case from the beginning when vmemmap_check_pmd() was added. I guess because arm64's > > > original vmemmap_populate() checked only for vmemmap_verify() as well. So probably > > > this does not need a "Fixes: " tag. > > > > I did not say the patch is wrong, only that it wouldn't be needed unless > > we have the other patch in this series. However, if we do apply the > > other patch, we definitely need this change, so keeping them together > > would make it easier to backport. > > Hi Catalin, > > Based on our current discussion on patchset #1, we will prohibit > hugepages(vmemmap mapping) for all hotplugging sections...The flow: > vmemmap_populate > vmemmap_populate_hugepages > vmemmap_check_pmd > > will *only* be called for non-early sections. Therefore, with patchset #1, I > don't see the patch as essential.. Would it be acceptable if we do not > backport this patch? Anshuman's suggestion seems reasonable to me and I > separated the patch out: > https://lore.kernel.org/lkml/20250102074047.674156-1-quic_zhenhuah@quicinc.com/ Ah, ok, so if you only call vmemmap_populate_basepages() for hotplugged memory, the vmemmap_check_pmd() won't even be called. So yeah, in this case there won't be any dependency on this change. If we somehow end up with a mix of vmemmap basepages and hugepages for hotplugged memory, we probably need to update vmemmap_check_pmd() as well (and backport together). -- Catalin