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] [thread-next>] [day] [month] [year] [list]

Message-ID: <86o6nb7oi1.fsf@kernel.org>
Date: Fri, 02 Jan 2026 21:23:18 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: Breno Leitao <leitao@...ian.org>
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,  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, 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?

[...]

-- 
Regards,
Pratyush Yadav