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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id E1800C0218A for ; Thu, 30 Jan 2025 07:44:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:List-Subscribe:List-Help :List-Post:List-Archive:List-Unsubscribe:List-Id:In-Reply-To:Content-Type: MIME-Version:References:Message-ID:Subject:Cc:To:From:Date:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=Jeh2QL0VpybbuD2GyYDiT3OJAH7l/aa4tMZhugnXW4g=; b=XELey6DrbJC0ifHuvdqF5dEcSu FKw03hmrbDPYDJ07tnOta2QqhdWLj9zAItdQJXq5q+dbNkwagibUQiRVhK+EBrEAbX6lrIIUXX2gw c3+dsGhJx/SES5th5H8yWfXoYqKMvxdjlFThntaXh56F+00Log2dFyFHDY9VL1deAr2m7f4ZHmGK8 869I3jS4aRh86tbGV5G2TFj+jDEp7sy52mw3K+n+Yx60N3LTKUUFoWZeTckZrc/0lsJYOFhSZfM4k N3wbhNxFy3cytb6KBr+tO28Kz29g6rcTl6DJpmwjtyqEQM0MFbAYc4VuSR0FppqbLaa2HA476WNO1 7fg7QcUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.98 #2 (Red Hat Linux)) id 1tdPE3-00000008NIi-3Zr4; Thu, 30 Jan 2025 07:44:35 +0000 Received: from dfw.source.kernel.org ([139.178.84.217]) by bombadil.infradead.org with esmtps (Exim 4.98 #2 (Red Hat Linux)) id 1tdPCj-00000008NCw-0j4P for linux-arm-kernel@lists.infradead.org; Thu, 30 Jan 2025 07:43:14 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 7CCD55C5E16; Thu, 30 Jan 2025 07:42:32 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B02EDC4CED2; Thu, 30 Jan 2025 07:43:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1738222992; bh=5J6jJrnq3XsDB9NlG9FzYa+g3HytaqGWsBfOymeBtSU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=ws446NIHaDfG++kFb3Hc1OTu4MRk+Xgff+axwOLG92mI95W8tFEsPOgivVlLiEZnS 6EuOM6xPO+whBvojZBC5W1SUPE9JmW/HWGfrvBh8KQMVUlNOCvKl1fQQ8g2QaxJZyo 6WbfqYS3nqfBA/ENbcd64t6hrzkpd2q1FsZtJXUI= Date: Thu, 30 Jan 2025 08:43:09 +0100 From: Greg KH To: Florian Fainelli Cc: stable@vger.kernel.org, Ard Biesheuvel , Anshuman Khandual , Will Deacon , Steven Price , Robin Murphy , Catalin Marinas , Baruch Siach , Petr Tesarik , Joey Gouly , "Mike Rapoport (IBM)" , Baoquan He , Yang Shi , "moderated list:ARM64 PORT (AARCH64 ARCHITECTURE)" , open list Subject: Re: [PATCH stable 5.4] arm64: mm: account for hotplug memory when randomizing the linear region Message-ID: <2025013002-discuss-twine-36b1@gregkh> References: <20250109165419.1623683-1-florian.fainelli@broadcom.com> <2025011217-swizzle-unusual-dd7b@gregkh> <213f28ff-2034-467e-8269-58b6e6f578df@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <213f28ff-2034-467e-8269-58b6e6f578df@broadcom.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20250129_234313_301023_5C719392 X-CRM114-Status: GOOD ( 46.22 ) 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: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Wed, Jan 29, 2025 at 10:05:29AM -0800, Florian Fainelli wrote: > On 1/12/25 03:53, Greg KH wrote: > > On Thu, Jan 09, 2025 at 08:54:16AM -0800, Florian Fainelli wrote: > > > From: Ard Biesheuvel > > > > > > commit 97d6786e0669daa5c2f2d07a057f574e849dfd3e upstream > > > > > > As a hardening measure, we currently randomize the placement of > > > physical memory inside the linear region when KASLR is in effect. > > > Since the random offset at which to place the available physical > > > memory inside the linear region is chosen early at boot, it is > > > based on the memblock description of memory, which does not cover > > > hotplug memory. The consequence of this is that the randomization > > > offset may be chosen such that any hotplugged memory located above > > > memblock_end_of_DRAM() that appears later is pushed off the end of > > > the linear region, where it cannot be accessed. > > > > > > So let's limit this randomization of the linear region to ensure > > > that this can no longer happen, by using the CPU's addressable PA > > > range instead. As it is guaranteed that no hotpluggable memory will > > > appear that falls outside of that range, we can safely put this PA > > > range sized window anywhere in the linear region. > > > > > > Signed-off-by: Ard Biesheuvel > > > Cc: Anshuman Khandual > > > Cc: Will Deacon > > > Cc: Steven Price > > > Cc: Robin Murphy > > > Link: https://lore.kernel.org/r/20201014081857.3288-1-ardb@kernel.org > > > Signed-off-by: Catalin Marinas > > > Signed-off-by: Florian Fainelli > > > --- > > > arch/arm64/mm/init.c | 13 ++++++++----- > > > 1 file changed, 8 insertions(+), 5 deletions(-) > > > > > > diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c > > > index cbcac03c0e0d..a6034645d6f7 100644 > > > --- a/arch/arm64/mm/init.c > > > +++ b/arch/arm64/mm/init.c > > > @@ -392,15 +392,18 @@ void __init arm64_memblock_init(void) > > > if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) { > > > extern u16 memstart_offset_seed; > > > - u64 range = linear_region_size - > > > - (memblock_end_of_DRAM() - memblock_start_of_DRAM()); > > > + u64 mmfr0 = read_cpuid(ID_AA64MMFR0_EL1); > > > + int parange = cpuid_feature_extract_unsigned_field( > > > + mmfr0, ID_AA64MMFR0_PARANGE_SHIFT); > > > + s64 range = linear_region_size - > > > + BIT(id_aa64mmfr0_parange_to_phys_shift(parange)); > > > /* > > > * If the size of the linear region exceeds, by a sufficient > > > - * margin, the size of the region that the available physical > > > - * memory spans, randomize the linear region as well. > > > + * margin, the size of the region that the physical memory can > > > + * span, randomize the linear region as well. > > > */ > > > - if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) { > > > + if (memstart_offset_seed > 0 && range >= (s64)ARM64_MEMSTART_ALIGN) { > > > range /= ARM64_MEMSTART_ALIGN; > > > memstart_addr -= ARM64_MEMSTART_ALIGN * > > > ((range * memstart_offset_seed) >> 16); > > > -- > > > 2.43.0 > > > > > > > > > > You are not providing any information as to WHY this is needed in stable > > kernels at all. It just looks like an unsolicted backport with no > > changes from upstream, yet no hint as to any bug it fixes. > > See the response in the other thread. > > > > > And you all really have hotpluggable memory on systems that are running > > th is old kernel? Why are they not using newer kernels if they need > > this? Surely lots of other bugs they need are resolved there, right? > > Believe it or not, but memory hotplug works really well for us, in a > somewhat limited configuration on the 5.4 kernel whereby we simply plug > memory, and never unplug it thereafter, but still, we have not had to carry > hotplug related patches other than this one. > > Trying to be a good citizen here: one of my colleague has identified an > upstream fix that works, that we got tested, cherry picked cleanly into both > 5.4 and 5.10, so it's not even like there was any fuzz. > > I was sort of hoping that giving my history of regularly testing stable > kernels for the past years, as well as submitting a fair amount of targeted > bug fixes to the stable branches that there would be some level of trust > here. Of course your history matters here, I'm not trying to disuade that at all. All I am saying is "this touches core arm64 code, so I would like an arm64 maintainer to at least glance at it to say it's ok to do this." And it looks like it now has happened, and it is good that I asked :) This is all normal, and good, I'm not singling you out here at all. We push back on backports all the time when we don't understand why they are being asked for and ask for a second review. You want us to do this in order to keep these trees working well. thanks, greg k-h