All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
Cc: akpm@linux-foundation.org,  bhe@redhat.com,  rppt@kernel.org,
	jasonmiu@google.com,  arnd@arndb.de,  coxu@redhat.com,
	dave@vasilevsky.ca,  ebiggers@google.com,  graf@amazon.com,
	kees@kernel.org,  linux-kernel@vger.kernel.org,
	kexec@lists.infradead.org,  linux-mm@kvack.org
Subject: Re: [PATCH v1 04/13] kho: Verify deserialization status and fix FDT alignment access
Date: Fri, 14 Nov 2025 17:52:37 +0100	[thread overview]
Message-ID: <mafs0tsyw7e0a.fsf@kernel.org> (raw)
In-Reply-To: <20251114155358.2884014-5-pasha.tatashin@soleen.com> (Pasha Tatashin's message of "Fri, 14 Nov 2025 10:53:49 -0500")

On Fri, Nov 14 2025, Pasha Tatashin wrote:

> During boot, kho_restore_folio() relies on the memory map having been
> successfully deserialized. If deserialization fails or no map is present,
> attempting to restore the FDT folio is unsafe.
>
> Update kho_mem_deserialize() to return a boolean indicating success. Use
> this return value in kho_memory_init() to disable KHO if deserialization
> fails. Also, the incoming FDT folio is never used, there is no reason to
> restore it.
>
> Additionally, use memcpy() to retrieve the memory map pointer from the FDT.
> FDT properties are not guaranteed to be naturally aligned, and accessing
> a 64-bit value via a pointer that is only 32-bit aligned can cause faults.
>
> Signed-off-by: Pasha Tatashin <pasha.tatashin@soleen.com>
> ---
>  kernel/liveupdate/kexec_handover.c | 32 ++++++++++++++++++------------
>  1 file changed, 19 insertions(+), 13 deletions(-)
>
> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> index a4b33ca79246..83aca3b4af15 100644
> --- a/kernel/liveupdate/kexec_handover.c
> +++ b/kernel/liveupdate/kexec_handover.c
> @@ -450,20 +450,28 @@ static void __init deserialize_bitmap(unsigned int order,
>  	}
>  }
>  
> -static void __init kho_mem_deserialize(const void *fdt)
> +/* Return true if memory was deserizlied */
> +static bool __init kho_mem_deserialize(const void *fdt)
>  {
>  	struct khoser_mem_chunk *chunk;
> -	const phys_addr_t *mem;
> +	const void *mem_ptr;
> +	u64 mem;
>  	int len;
>  
> -	mem = fdt_getprop(fdt, 0, PROP_PRESERVED_MEMORY_MAP, &len);
> -
> -	if (!mem || len != sizeof(*mem)) {
> +	mem_ptr = fdt_getprop(fdt, 0, PROP_PRESERVED_MEMORY_MAP, &len);
> +	if (!mem_ptr || len != sizeof(u64)) {
>  		pr_err("failed to get preserved memory bitmaps\n");
> -		return;
> +		return false;
>  	}
> +	/* FDT guarantees 32-bit alignment, have to use memcpy */
> +	memcpy(&mem, mem_ptr, len);

Perhaps get_unaligned(mem) would have been simpler?

> +
> +	chunk = mem ? phys_to_virt(mem) : NULL;
> +
> +	/* No preserved physical pages were passed, no deserialization */
> +	if (!chunk)
> +		return false;

Should we disallow all kho_restore_{folio,pages}() calls too if this
fails? Ideally those should never happen since kho_retrieve_subtree()
will fail, so maybe as a debug aid?

>  
> -	chunk = *mem ? phys_to_virt(*mem) : NULL;
>  	while (chunk) {
>  		unsigned int i;
>  
> @@ -472,6 +480,8 @@ static void __init kho_mem_deserialize(const void *fdt)
>  					   &chunk->bitmaps[i]);
>  		chunk = KHOSER_LOAD_PTR(chunk->hdr.next);
>  	}
> +
> +	return true;
>  }
>  
>  /*
> @@ -1377,16 +1387,12 @@ static void __init kho_release_scratch(void)
>  
>  void __init kho_memory_init(void)
>  {
> -	struct folio *folio;
> -
>  	if (kho_in.scratch_phys) {
>  		kho_scratch = phys_to_virt(kho_in.scratch_phys);
>  		kho_release_scratch();
>  
> -		kho_mem_deserialize(kho_get_fdt());
> -		folio = kho_restore_folio(kho_in.fdt_phys);
> -		if (!folio)
> -			pr_warn("failed to restore folio for KHO fdt\n");
> +		if (!kho_mem_deserialize(kho_get_fdt()))
> +			kho_in.fdt_phys = 0;

The folio restore does serve a purpose: it accounts for that folio in
the system's total memory. See the call to adjust_managed_page_count()
in kho_restore_page(). In practice, I don't think it makes much of a
difference, but I don't see why not.

>  	} else {
>  		kho_reserve_scratch();
>  	}

-- 
Regards,
Pratyush Yadav


  reply	other threads:[~2025-11-14 16:52 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-14 15:53 [PATCH v1 00/13] kho: simplify state machine and enable dynamic updates Pasha Tatashin
2025-11-14 15:53 ` [PATCH v1 01/13] kho: Fix misleading log message in kho_populate() Pasha Tatashin
2025-11-14 16:32   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 02/13] kho: Convert __kho_abort() to return void Pasha Tatashin
2025-11-14 16:32   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 03/13] kho: Preserve FDT folio only once during initialization Pasha Tatashin
2025-11-14 16:32   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 04/13] kho: Verify deserialization status and fix FDT alignment access Pasha Tatashin
2025-11-14 16:52   ` Pratyush Yadav [this message]
2025-11-14 17:21     ` Pasha Tatashin
2025-11-15  9:36     ` Mike Rapoport
2025-11-18 13:19       ` Pratyush Yadav
2025-11-18 15:25         ` Pasha Tatashin
2025-11-18 17:11           ` Pratyush Yadav
2025-11-20 10:39             ` Mike Rapoport
2025-11-14 15:53 ` [PATCH v1 05/13] kho: Always expose output FDT in debugfs Pasha Tatashin
2025-11-14 16:59   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 06/13] kho: Simplify serialization and remove __kho_abort Pasha Tatashin
2025-11-14 17:04   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 07/13] kho: Remove global preserved_mem_map and store state in FDT Pasha Tatashin
2025-11-14 17:11   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 08/13] kho: Remove abort functionality and support state refresh Pasha Tatashin
2025-11-14 17:18   ` Pratyush Yadav
2025-11-14 17:23     ` Pasha Tatashin
2025-11-14 17:47       ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 09/13] kho: Update FDT dynamically for subtree addition/removal Pasha Tatashin
2025-11-14 16:15   ` Mike Rapoport
2025-11-14 16:42     ` Pasha Tatashin
2025-11-14 17:27   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 10/13] kho: Allow kexec load before KHO finalization Pasha Tatashin
2025-11-14 17:30   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 11/13] kho: Allow memory preservation state updates after finalization Pasha Tatashin
2025-11-14 17:33   ` Pratyush Yadav
2025-11-14 17:47     ` Pasha Tatashin
2025-11-14 15:53 ` [PATCH v1 12/13] kho: Add Kconfig option to enable KHO by default Pasha Tatashin
2025-11-14 17:34   ` Pratyush Yadav
2025-11-14 15:53 ` [PATCH v1 13/13] kho: Introduce high-level memory allocation API Pasha Tatashin
2025-11-14 16:15   ` Mike Rapoport
2025-11-14 16:40     ` Pasha Tatashin
2025-11-14 17:45   ` Pratyush Yadav
2025-11-14 17:54     ` Pasha Tatashin
2025-11-14 16:17 ` [PATCH v1 00/13] kho: simplify state machine and enable dynamic updates Mike Rapoport
2025-11-14 16:46   ` Pasha Tatashin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=mafs0tsyw7e0a.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=bhe@redhat.com \
    --cc=coxu@redhat.com \
    --cc=dave@vasilevsky.ca \
    --cc=ebiggers@google.com \
    --cc=graf@amazon.com \
    --cc=jasonmiu@google.com \
    --cc=kees@kernel.org \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=rppt@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.