Re: [PATCH v2 2/2] kexec: history: track kexec boot counter

[Usama Arif <usamaarif642@gmail.com>]

On 02/01/2026 18:24, Breno Leitao wrote:
> Hello Usama,
> 
> On Fri, Jan 02, 2026 at 06:09:57PM +0300, Usama Arif wrote:
>>
>> On 02/01/2026 17:53, Breno Leitao wrote:
>>> Track and display the number of kexec boots since the last cold reboot
>>> when CONFIG_KEXEC_HISTORY is enabled.
>>>
>>> This extends the previous kernel release tracking feature by adding
>>> a counter that increments with each kexec boot. The counter provides
>>> visibility into the kexec chain depth, which is useful for understanding
>>> boot history in production environments.
>>>
>>> Add a new property, "kexec-count" in KHO FDT alongside the existing
>>> "previous-release" property. The counter is:
>>>
>>>  - Initialized to 0 when kho_in is instantiated.
>>>  - Incremented by 1 on each subsequent kexec.
>>>  - Printed alongside the previous kernel release version.
>>>
>>> The counter is stored as a 32-bit unsigned integer in FDT format and is
>>> only active when CONFIG_KEXEC_HISTORY is enabled.
>>>
>>> Signed-off-by: Breno Leitao <leitao@debian.org>
>>> Suggested-by: Pasha Tatashin <pasha.tatashin@soleen.com>
>>> ---
>>>  kernel/liveupdate/kexec_handover.c | 25 +++++++++++++++++++++++--
>>>  1 file changed, 23 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>>> index 06d99627bb3c..fe5a2c5c4c86 100644
>>> --- a/kernel/liveupdate/kexec_handover.c
>>> +++ b/kernel/liveupdate/kexec_handover.c
>>> @@ -38,6 +38,7 @@
>>>  #define PROP_PRESERVED_MEMORY_MAP "preserved-memory-map"
>>>  #define PROP_SUB_FDT "fdt"
>>>  #define PROP_PREVIOUS_RELEASE "previous-release"
>>> +#define PROP_KEXEC_COUNT "kexec-count"
>>>  
>>>  #define KHO_PAGE_MAGIC 0x4b484f50U /* ASCII for 'KHOP' */
>>>  
>>> @@ -1257,6 +1258,7 @@ struct kho_in {
>>>  	phys_addr_t scratch_phys;
>>>  #ifdef CONFIG_KEXEC_HISTORY
>>>  	char previous_release[__NEW_UTS_LEN + 1];
>>> +	u32 kexec_count;
>>>  #endif
>>>  	struct kho_debugfs dbg;
>>>  };
>>> @@ -1330,6 +1332,9 @@ static __init int kho_out_fdt_setup(void)
>>>  	void *root = kho_out.fdt;
>>>  	u64 empty_mem_map = 0;
>>>  	int err;
>>> +#ifdef CONFIG_KEXEC_HISTORY
>>> +	u32 kexec_count;
>>> +#endif
>>>  
>>>  	err = fdt_create(root, PAGE_SIZE);
>>>  	err |= fdt_finish_reservemap(root);
>>> @@ -1340,6 +1345,10 @@ static __init int kho_out_fdt_setup(void)
>>>  #ifdef CONFIG_KEXEC_HISTORY
>>>  	err |= fdt_property_string(root, PROP_PREVIOUS_RELEASE,
>>>  				   init_uts_ns.name.release);
>>> +	/* kho_in.kexec_count is set to 0 on cold boot */
>>> +	kexec_count = cpu_to_fdt32(kho_in.kexec_count + 1);
>>
>> Should this be kexec_count = cpu_to_fdt32(kho_in.kexec_count) + 1; ?
> 
> I don't think so. Basically we want to increment the counter in native
> endianess and then convert to the Big Endian (FDT/DT are big endian
> AFAIK) and then store (line below) to the DT.
> 
> If we convert to big endian and then sum 1, it will mess with the
> result. 

ack, Thanks for explaining, I didnt think of endianess!

> 
>> +    err |= fdt_property(root, PROP_KEXEC_COUNT, &kexec_count,
>>> +                sizeof(kexec_count));
> 
> Thanks for the review,
> --breno