[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <rsygqnm3qahkfoqo6usrz3jhpya3c3rqebz6rotl33dsx3rsbo@2v4yeabi7fda>
Date: Fri, 2 Jan 2026 07:24:54 -0800
From: Breno Leitao <leitao@...ian.org>
To: Usama Arif <usamaarif642@...il.com>
Cc: Alexander Graf <graf@...zon.com>, Mike Rapoport <rppt@...nel.org>,
Pasha Tatashin <pasha.tatashin@...een.com>, Pratyush Yadav <pratyush@...nel.org>,
linux-kernel@...r.kernel.org, kexec@...ts.infradead.org, linux-mm@...ck.org, rmikey@...a.com,
clm@...com, riel@...riel.com, kernel-team@...a.com
Subject: Re: [PATCH v2 2/2] kexec: history: track kexec boot counter
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@...ian.org>
> > Suggested-by: Pasha Tatashin <pasha.tatashin@...een.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.
> + err |= fdt_property(root, PROP_KEXEC_COUNT, &kexec_count,
> > + sizeof(kexec_count));
Thanks for the review,
--breno
Powered by blists - more mailing lists