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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <w542cckfixvgo6pvepdg6itaera6qlq75pemqvpah7us6c7yxa@6vm7ebxd6ala>
Date: Tue, 6 Jan 2026 03:04:28 -0800
From: Breno Leitao <leitao@...ian.org>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Alexander Graf <graf@...zon.com>, Mike Rapoport <rppt@...nel.org>, 
	Pasha Tatashin <pasha.tatashin@...een.com>, linux-kernel@...r.kernel.org, kexec@...ts.infradead.org, 
	linux-mm@...ck.org, usamaarif642@...il.com, rmikey@...a.com, clm@...com, 
	riel@...riel.com, kernel-team@...a.com
Subject: Re: [PATCH v2 2/2] kexec: history: track kexec boot counter

On Fri, Jan 02, 2026 at 09:23:18PM +0100, Pratyush Yadav wrote:
> On Fri, Jan 02 2026, Breno Leitao wrote:
> 
> > Track and display the number of kexec boots since the last cold reboot
> 
> Nit: this does not track kexec boots, it tracks KHO boots. None of this
> can work on normal kexec boots. Can you please update the wording to
> make that clear?
> 
> > 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.
> 
> We have such a counter for LUO as well from the properly
> "liveupdate-number". If you're using LUO, why can't you use that counter
> directly?
> 
> If you're not using LUO, I'm curious, what's your use case? Right now
> KHO only supports reserve-mem outside of LUO. Is that what you plan to
> use?
> 
> Also, do we want to keep both counters independently? Or do we have one
> and drop the other? Pasha, what do you think?

In fact, I do not have plan to use LUO right now. My goal is to pass the
kexec release from kernel to another, and for that I am using KHO to
pass this information.

That said, I am planning to use KHO as the infrastructure to pass the
kernel version from one kernel to another.

Given that I don't think this "feature" should depend on LUO, maybe the
counters should be independent (?!)

Thanks
--breno