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

[Pratyush Yadav <pratyush@kernel.org>]

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.

>
> Link: https://lore.kernel.org/all/20260108-kho-v3-0-b1d6b7a89342@debian.org/ [1]
>
> --breno

-- 
Regards,
Pratyush Yadav