Re: [PATCH v4] kho: kexec-metadata: track previous kernel chain

[Pratyush Yadav <pratyush@kernel.org>]

On Mon, Jan 26 2026, Pratyush Yadav wrote:

> Hi Breno,
>
> On Mon, Jan 26 2026, Breno Leitao wrote:
>
>> On Wed, Jan 21, 2026 at 06:50:38AM -0800, Breno Leitao wrote:
>>> +static __init int kho_populate_kexec_metadata(void)
>>> +{
>>> +	struct kho_kexec_metadata *metadata;
>>> +	int err;
>>> +
>>> +	metadata = kho_alloc_preserve(sizeof(*metadata));
>>> +	if (IS_ERR(metadata))
>>> +		return PTR_ERR(metadata);
>>> +
>>> +	strscpy(metadata->previous_release, init_uts_ns.name.release,
>>> +		sizeof(metadata->previous_release));
>>> +	/* kho_in.kexec_count is set to 0 on cold boot */
>>> +	metadata->kexec_count = kho_in.kexec_count + 1;
>>> +
>>> +	err = kho_add_subtree(KHO_METADATA_NODE_NAME, metadata);
>>
>> There is a hidden bug in here when CONFIG_KEXEC_HANDOVER_DEBUGFS is set.
>
> Good catch!
>
>>
>> kho_add_subtree() expects a fdt as the second argument, and we are
>> passing a pure C struct. That works fine, except for debugfs, which
>> does:
>>
>>  1. kho_add_subtree() calls kho_debugfs_fdt_add()
>>  2. kho_debugfs_fdt_add() calls __kho_debugfs_fdt_add()
>>  3. __kho_debugfs_fdt_add() executes fdt_totalsize(fdt)
>>
>> The fdt_totalsize() macro reads bytes 4-7 of the input as a big-endian u32, and
>> this will hit struct kho_kexec_metadata, given I am passing a C struct instead
>> of a FDT.
>>
>>   struct kho_kexec_metadata {
>>       char previous_release[__NEW_UTS_LEN + 1];  // 65 bytes
>>       u32 kexec_count;
>>   } __packed;
>>
>> Bytes 4-7 would be characters from previous_release (e.g., "0-rc" from
>> "6.19.0-rc4..."). Interpreted as big-endian u32, this gives a garbage size
>> value.
>>
>> The alternatives I see here are:
>>
>>  1) Come back to FDT instead of plain C struct, similarly to the previous
>>     version [1]
>>  2) Created some helpers to treat C struct fields specially just for this
>>     feature, and we can do it later if we have more users.
>>  3) Move this kexec_metadata to work on top of LUO (similarly to memfd), but
>>     that would be an unnecessary dependency just to have this kexec_metadata.
>>
>> That said, for the next version, I am coming back to to FDT.
>
> Please, no. Don't go back to it just for the sake of this bug.
>
> I think KHO's assumption that the subtree will always point to an FDT is
> broken, and we should fix that. I think KHO should expose the blob of
> serialized data and let userspace figure out what the format is and how
> to decode it.
>
> To do that, we would need to update kho_add_subtree() to take a size
> parameter from callers, and pass that down to debugfs code. I count 3
> callers of kho_add_subtree() - memblock, LUO, and test_kho. I think all
> 3 should be fairly easy to update, but I am happy to help out if you
> need.

As an example, I'd do something along the lines of:

diff --git a/mm/memblock.c b/mm/memblock.c
index 905d06b16348..c06d6b9e390b 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -2512,7 +2512,7 @@ static int __init prepare_kho_fdt(void)
 	if (err)
 		goto err_unpreserve_fdt;
 
-	err = kho_add_subtree(MEMBLOCK_KHO_FDT, fdt);
+	err = kho_add_subtree(MEMBLOCK_KHO_FDT, fdt, fdt_totalsize(fdt));
 	if (err)
 		goto err_unpreserve_fdt;

-- 
Regards,
Pratyush Yadav