kho_kexec_metadata_init() was placed after the fdt check, causing it to
run only on the fresh boot path (no incoming FDT) and skipping metadata
initialization on the KHO restore path.

The original patch[1] was based on commit 5c9e55fecf93658 ("Add linux-next
specific files for 20260312"), which included commit d7176a010afce8
("kho: fix deferred init of kho scratch"). That commit has since been
rebased and reworked in linux-next, changing the code flow so that
kho_kexec_metadata_init() is no longer reached on the restore path.

Fix this by moving the call before the fdt check so it runs regardless
of whether an incoming FDT is present.

Link: https://lore.kernel.org/all/20260309-kho-v8-5-c3abcf4ac750@debian.org/ [1]
Fixes: 047117e78331a ("kho: kexec-metadata: track previous kernel chain")
Signed-off-by: Breno Leitao <leitao@debian.org>
---
 kernel/liveupdate/kexec_handover.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 5e8206235d99e..94762de1fe5f0 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -1519,15 +1519,15 @@ static __init int kho_init(void)
 	if (err)
 		goto err_free_fdt;
 
+	err = kho_kexec_metadata_init(fdt);
+	if (err)
+		goto err_free_fdt;
+
 	if (fdt) {
 		kho_in_debugfs_init(&kho_in.dbg, fdt);
 		return 0;
 	}
 
-	err = kho_kexec_metadata_init(fdt);
-	if (err)
-		goto err_free_fdt;
-
 	for (int i = 0; i < kho_scratch_cnt; i++) {
 		unsigned long base_pfn = PHYS_PFN(kho_scratch[i].addr);
 		unsigned long count = kho_scratch[i].size >> PAGE_SHIFT;

---
base-commit: db7efce4ae23ad5e42f5f55428f529ff62b86fab
change-id: 20260409-kho_fix_merge_issue-dab886bb4a15

Best regards,
--  
Breno Leitao <leitao@debian.org>

On Thu, Apr 09 2026, Breno Leitao wrote:

> kho_kexec_metadata_init() was placed after the fdt check, causing it to
> run only on the fresh boot path (no incoming FDT) and skipping metadata
> initialization on the KHO restore path.
>
> The original patch[1] was based on commit 5c9e55fecf93658 ("Add linux-next
> specific files for 20260312"), which included commit d7176a010afce8
> ("kho: fix deferred init of kho scratch"). That commit has since been
> rebased and reworked in linux-next, changing the code flow so that
> kho_kexec_metadata_init() is no longer reached on the restore path.
>
> Fix this by moving the call before the fdt check so it runs regardless
> of whether an incoming FDT is present.
>
> Link: https://lore.kernel.org/all/20260309-kho-v8-5-c3abcf4ac750@debian.org/ [1]
> Fixes: 047117e78331a ("kho: kexec-metadata: track previous kernel chain")
> Signed-off-by: Breno Leitao <leitao@debian.org>

Acked-by: Pratyush Yadav <pratyush@kernel.org>

Andrew, since the patch "kho: kexec-metadata: track previous kernel
chain" is still in mm-unstable, please meld this patch into it if
possible.

[...]

-- 
Regards,
Pratyush Yadav

On Thu, Apr 09, 2026 at 03:31:40AM -0700, Breno Leitao wrote:
> kho_kexec_metadata_init() was placed after the fdt check, causing it to
> run only on the fresh boot path (no incoming FDT) and skipping metadata
> initialization on the KHO restore path.
> 
> The original patch[1] was based on commit 5c9e55fecf93658 ("Add linux-next
> specific files for 20260312"), which included commit d7176a010afce8
> ("kho: fix deferred init of kho scratch"). That commit has since been
> rebased and reworked in linux-next, changing the code flow so that
> kho_kexec_metadata_init() is no longer reached on the restore path.
> 
> Fix this by moving the call before the fdt check so it runs regardless
> of whether an incoming FDT is present.
> 
> Link: https://lore.kernel.org/all/20260309-kho-v8-5-c3abcf4ac750@debian.org/ [1]
> Fixes: 047117e78331a ("kho: kexec-metadata: track previous kernel chain")
> Signed-off-by: Breno Leitao <leitao@debian.org>

Acked-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

> ---
>  kernel/liveupdate/kexec_handover.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)

-- 
Sincerely yours,
Mike.