From: Breno Leitao <leitao@debian.org>
To: Alexander Graf <graf@amazon.com>, Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>
Cc: linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
linux-mm@kvack.org, usamaarif642@gmail.com, rmikey@meta.com,
clm@fb.com, riel@surriel.com, Breno Leitao <leitao@debian.org>,
SeongJae Park <sj@kernel.org>,
kernel-team@meta.com
Subject: [PATCH v6 0/4] kho: history: track previous kernel version and kexec boot count
Date: Tue, 27 Jan 2026 06:37:35 -0800 [thread overview]
Message-ID: <20260127-kho-v6-0-56f9396681c2@debian.org> (raw)
Use Kexec Handover (KHO) to pass the previous kernel's version string
and the number of kexec reboots since the last cold boot to the next
kernel, and print it at boot time.
Example
=======
[ 0.000000] Linux version 6.19.0-rc3-upstream-00047-ge5d992347849
...
[ 0.000000] KHO: exec from: 6.19.0-rc4-next-20260107upstream-00004-g3071b0dc4498 (count 1)
Motivation
==========
Bugs that only reproduce when kexecing from specific kernel versions
are difficult to diagnose. These issues occur when a buggy kernel
kexecs into a new kernel, with the bug manifesting only in the second
kernel.
Recent examples include:
* eb2266312507 ("x86/boot: Fix page table access in 5-level to 4-level paging transition")
* 77d48d39e991 ("efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption")
* 64b45dd46e15 ("x86/efi: skip memattr table on kexec boot")
As kexec-based reboots become more common, these version-dependent bugs
are appearing more frequently. At scale, correlating crashes to the
previous kernel version is challenging, especially when issues only
occur in specific transition scenarios.
Some bugs manifest only after multiple consecutive kexec reboots.
Tracking the kexec count helps identify these cases (this metric is
already used by live update sub-system).
KHO provides a reliable mechanism to pass information between kernels.
By carrying the previous kernel's release string and kexec count
forward, we can print this context at boot time to aid debugging.
The goal of this feature is to have this information being printed in
early boot, so, users can trace back kernel releases in kexec. Systemd
is not helpful because we cannot assume that the previous kernel has
systemd or even write access to the disk (common when using Linux as
bootloaders)
Signed-off-by: Breno Leitao <leitao@debian.org>
Acked-by: SeongJae Park <sj@kernel.org>
---
Changes in v6:
- s/UAPI/uABI (Mike)
- Expanded the rename of s/fdt/blob to kho_debugfs_* calls also (Mike)
- Link to v5: https://patch.msgid.link/20260126-kho-v5-0-7cd0f69ab204@debian.org
Changes in v5:
- Add a patch to document the new feature.
- Change kho_add_subtree() to receive the size instad of guessing it.
- reworked some code path to make it more standard.
- Link to v4: https://patch.msgid.link/20260121-kho-v4-1-5c8fe77b6804@debian.org
Changes in v4:
- Squashed everything in a single commit
- Moved from FDT to C structs (Pratyush)
- Usage of subtress intead of FDT directly (Pratyush)
- Renamed a bunch of variables and functions.
- Link to v3: https://patch.msgid.link/20260108-kho-v3-0-b1d6b7a89342@debian.org
Changes in v3:
- Remove the extra CONFIG for this feature.
- Reworded some identifiers, properties and printks.
- Better documented the questions raised during v2.
- Link to v2: https://patch.msgid.link/20260102-kho-v2-0-1747b1a3a1d6@debian.org
Changes from v2 to v1 (RFC)
- Track the number of kexecs since cold boot (Pasha)
- Change the printk() order compared to KHO
- Rewording of the commit summary
- Link to RFC: https://patch.msgid.link/20251230-kho-v1-1-4d795a24da9e@debian.org
---
Breno Leitao (4):
kho: add size parameter to kho_add_subtree()
kho: rename fdt parameter to blob in kho_add/remove_subtree()
kho: kexec-metadata: track previous kernel chain
kho: document kexec-metadata tracking feature
Documentation/admin-guide/mm/kho.rst | 39 ++++++++++++
include/linux/kexec_handover.h | 8 +--
include/linux/kho/abi/kexec_handover.h | 31 +++++++++
kernel/liveupdate/kexec_handover.c | 99 +++++++++++++++++++++++++----
kernel/liveupdate/kexec_handover_debugfs.c | 28 ++++----
kernel/liveupdate/kexec_handover_internal.h | 15 +++--
kernel/liveupdate/luo_core.c | 3 +-
lib/test_kho.c | 3 +-
mm/memblock.c | 2 +-
9 files changed, 191 insertions(+), 37 deletions(-)
---
base-commit: ca3a02fda4da8e2c1cb6baee5d72352e9e2cfaea
change-id: 20251230-kho-7707e8a2ef1e
Best regards,
--
Breno Leitao <leitao@debian.org>
next reply other threads:[~2026-01-27 14:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-27 14:37 Breno Leitao [this message]
2026-01-27 14:37 ` [PATCH v6 1/4] kho: add size parameter to kho_add_subtree() Breno Leitao
2026-02-04 13:54 ` Pratyush Yadav
2026-01-27 14:37 ` [PATCH v6 2/4] kho: rename fdt parameter to blob in kho_add/remove_subtree() Breno Leitao
2026-01-27 14:43 ` Mike Rapoport
2026-01-27 14:37 ` [PATCH v6 3/4] kho: kexec-metadata: track previous kernel chain Breno Leitao
2026-01-27 14:37 ` [PATCH v6 4/4] kho: document kexec-metadata tracking feature Breno Leitao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260127-kho-v6-0-56f9396681c2@debian.org \
--to=leitao@debian.org \
--cc=clm@fb.com \
--cc=graf@amazon.com \
--cc=kernel-team@meta.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=riel@surriel.com \
--cc=rmikey@meta.com \
--cc=rppt@kernel.org \
--cc=sj@kernel.org \
--cc=usamaarif642@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox