From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 455A128C2A1 for ; Sun, 2 Aug 2026 11:25:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785669933; cv=none; b=VBbo6ndKuOBTIDeF6XYpcYs89Grx2Uh5EsDN8l1LMxxaAgl7t63s9Mf+vttuMrTtnvjtuVirFgDgunsyoZ1IMjq2gOMlsL81Vetlye5gZETDEk6zGvkOrYRX4TFfz+pOcJSV81RhjqFguQddpT1PVNo0LXprSyLNBbnBpgbYVR8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785669933; c=relaxed/simple; bh=NeONxBVi/9B4I39ZudyWUDt4uGUz0rpbMGHpb9ESvEI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=WCd/mIwQNLNRxKk7s7RtIErELs+Z+i6SyQMek02sfV71nXSuylB3/MQpR4qgJ1/eixA5FzmgqvYHgu8Vi5QxIIFihPlRDi9/EU2qvyqjOBrQ0e23/ZYOYdxXwxJ3xlyQdMuPm+34vZU18s/XbbnScJpUCDi52VKnP9GI2nhEIN4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UdHSFmIU; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UdHSFmIU" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 717591F000E9; Sun, 2 Aug 2026 11:25:28 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785669931; bh=FqGL/ivu0kPMFEoqQ4nvJHR3lkRTVyHnKZqNJ5UqfJw=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=UdHSFmIUrefEUW2F0hPEyBcCVPw1XXJjlW1RaBg2UmleH4ra6hVKzCgK7xN9wMApt Frrt61qEC8uAoiqw1WzSBukPaU+7+rX3Z4vptgMqVqwjoFuobTxOUVYUNoomCa38Y0 7KjQxky2138aS9nFyLfzMGMON4v5xuwTLhAiDf6pjTthfDHLEfH4jHvY8OczLq7KZj rOfvi22ec3G/rQBqONbDbmQ3zn5zH8cssC/EE+dx391nsoMSTAQSHakhkT6fNprPhW wuoEQEGWOzSGMWvd2/w0VB16SKN5y+4/fbMqYFoWKaKqie9+8UVVBa/L1idd+nxz7u 3w1Zmr7xOgS8A== Date: Sun, 2 Aug 2026 14:25:24 +0300 From: Mike Rapoport To: Pratyush Yadav Cc: Pasha Tatashin , Alexander Graf , Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , Jason Miu , Jork Loeser , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 04/22] kho: return virtual address of mem_map from kho_get_mem_map() Message-ID: References: <20260801084833.1897543-1-pratyush@kernel.org> <20260801084833.1897543-5-pratyush@kernel.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260801084833.1897543-5-pratyush@kernel.org> On Sat, Aug 01, 2026 at 10:48:13AM +0200, Pratyush Yadav wrote: > From: "Pratyush Yadav (Google)" > > Currently the preserved memory map address is returned by > kho_get_mem_map_phys(). It is only used by kho_populate(). > kho_populate() doesn't use the actual value. It only cares that the > address exists and is valid. > > In coming patches, more callers will be added, all of which will need > the virtual address of the preserved memory map. Since kho_populate() > doesn't care about the actual value and only cares about validity, it > can also use the virtual address returned by kho_get_mem_map(). It only > needs to make sure the returned value is not NULL. > > Rename kho_get_mem_map_phys() to kho_get_mem_map() and return the > virtual address of the preserved memory map. > > Signed-off-by: Pratyush Yadav (Google) > --- > kernel/liveupdate/kexec_handover.c | 25 +++++++++++++++++-------- > 1 file changed, 17 insertions(+), 8 deletions(-) > > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c > index e7451743b87e..5c35c11c273b 100644 > --- a/kernel/liveupdate/kexec_handover.c > +++ b/kernel/liveupdate/kexec_handover.c > @@ -512,19 +512,24 @@ static int __init kho_preserved_memory_reserve(unsigned long key) > return 0; > } > > -/* Returns physical address of the preserved memory map from FDT */ > -static phys_addr_t __init kho_get_mem_map_phys(const void *fdt) > +/* Returns virtual address of the preserved memory map from FDT */ > +static __init void *kho_get_mem_map(const void *fdt) > { > const void *mem_ptr; > + phys_addr_t mem_map_phys; > int len; > > mem_ptr = fdt_getprop(fdt, 0, KHO_FDT_MEMORY_MAP_PROP_NAME, &len); > if (!mem_ptr || len != sizeof(u64)) { > pr_err("failed to get preserved memory map\n"); > - return 0; > + return NULL; > } > > - return get_unaligned((const u64 *)mem_ptr); > + mem_map_phys = get_unaligned((const u64 *)mem_ptr); > + if (!mem_map_phys) > + return NULL; > + > + return phys_to_virt(mem_map_phys); This time sashiko found a real issue with this on arm64: Will calling phys_to_virt() unconditionally here cause a panic on ARM64 during early boot? When booting with KHO properties, early_init_dt_scan() calls kho_populate() which then calls kho_get_mem_map(). Since this happens before arm64_memblock_init() sets up memstart_addr, the internal phys_to_virt() implementation evaluates PHYS_OFFSET with an uninitialized memstart_addr. This fails the VM_BUG_ON(memstart_addr & 1) assertion when CONFIG_DEBUG_VM is enabled. I fixed this up by keeping kho_get_mem_map_phys() and adding a thin kho_get_mem_map() that returns the virtual address. This caused some rebase conflicts afterwards, please check I didn't mess up anything :) > } > > /* > @@ -1647,9 +1652,8 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len, > { > unsigned int scratch_cnt = scratch_len / sizeof(*kho_scratch); > struct kho_scratch *scratch = NULL; > - phys_addr_t mem_map_phys; > - void *fdt = NULL; > bool populated = false; > + void *fdt = NULL; > int err; > > /* Validate the input FDT */ > @@ -1671,8 +1675,13 @@ void __init kho_populate(phys_addr_t fdt_phys, u64 fdt_len, > goto unmap_fdt; > } > > - mem_map_phys = kho_get_mem_map_phys(fdt); > - if (!mem_map_phys) > + /* > + * At this point phys_to_virt() doesn't work properly and so > + * kho_get_mem_map() can return a pre-KASLR virtual address. But here we > + * only want to make sure the mem_map is valid so the actual value > + * doesn't matter as long as it isn't NULL. > + */ > + if (!kho_get_mem_map(fdt)) > goto unmap_fdt; > > scratch = early_memremap(scratch_phys, scratch_len); > -- > 2.55.0.571.g244d577d93-goog > -- Sincerely yours, Mike.