Re: [PATCH v6 04/22] kho: return virtual address of mem_map from kho_get_mem_map()

Mike Rapoport <[email protected]>
Newsgroups gmane.linux.kernel.kexec,gmane.linux.kernel.mm,gmane.linux.kernel
Message-ID <[email protected]>
On Sat, Aug 01, 2026 at 10:48:13AM +0200, Pratyush Yadav wrote:
> From: "Pratyush Yadav (Google)" <[email protected]>
> 
> 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) <[email protected]>
> ---
>  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.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.