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
