All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pratyush Yadav <pratyush@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Alexander Graf <graf@amazon.com>,
	 Mike Rapoport <rppt@kernel.org>,
	Pasha Tatashin <pasha.tatashin@soleen.com>,
	 Pratyush Yadav <pratyush@kernel.org>,
	 linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
	 linux-mm@kvack.org,  usama.arif@linux.dev,
	SeongJae Park <sj@kernel.org>,
	 kernel-team@meta.com
Subject: Re: [PATCH v9 5/6] kho: kexec-metadata: track previous kernel chain
Date: Fri, 03 Apr 2026 11:29:08 +0000	[thread overview]
Message-ID: <2vxzika8cmez.fsf@kernel.org> (raw)
In-Reply-To: <20260316-kho-v9-5-ed6dcd951988@debian.org> (Breno Leitao's message of "Mon, 16 Mar 2026 04:54:35 -0700")

On Mon, Mar 16 2026, Breno Leitao wrote:

> 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 output:
>     [    0.000000] KHO: exec from: 6.19.0-rc4-next-20260107 (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 the following commits:
>
>  * commit eb2266312507 ("x86/boot: Fix page table access in
>    5-level to 4-level paging transition")
>  * commit 77d48d39e991 ("efistub/tpm: Use ACPI reclaim memory
>    for event log to avoid corruption")
>  * commit 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.
>
> Implementation
> ==============
>
> The kexec metadata is stored as a plain C struct (struct kho_kexec_metadata)
> rather than FDT format, for simplicity and direct field access. It is
> registered via kho_add_subtree() as a separate subtree, keeping it
> independent from the core KHO ABI. This design choice:
>
>  - Keeps the core KHO ABI minimal and stable
>  - Allows the metadata format to evolve independently
>  - Avoids requiring version bumps for all KHO consumers (LUO, etc.)
>    when the metadata format changes
>
> The struct kho_kexec_metadata contains two fields:
>  - previous_release: The kernel version that initiated the kexec
>  - kexec_count: Number of kexec boots since last cold boot
>
> On cold boot, kexec_count starts at 0 and increments with each kexec.
> The count helps identify issues that only manifest after multiple
> consecutive kexec reboots.
>
> Acked-by: SeongJae Park <sj@kernel.org>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Signed-off-by: Breno Leitao <leitao@debian.org>

Reviewed-by: Pratyush Yadav <pratyush@kernel.org>

[...]

-- 
Regards,
Pratyush Yadav


  reply	other threads:[~2026-04-03 11:29 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-16 11:54 [PATCH v9 0/6] kho: history: track previous kernel version and kexec boot count Breno Leitao
2026-03-16 11:54 ` [PATCH v9 1/6] kho: add size parameter to kho_add_subtree() Breno Leitao
2026-04-03 11:21   ` Pratyush Yadav
2026-03-16 11:54 ` [PATCH v9 2/6] kho: rename fdt parameter to blob in kho_add/remove_subtree() Breno Leitao
2026-03-16 11:54 ` [PATCH v9 3/6] kho: persist blob size in KHO FDT Breno Leitao
2026-04-03 11:24   ` Pratyush Yadav
2026-03-16 11:54 ` [PATCH v9 4/6] kho: fix kho_in_debugfs_init() to handle non-FDT blobs Breno Leitao
2026-04-03 11:27   ` Pratyush Yadav
2026-03-16 11:54 ` [PATCH v9 5/6] kho: kexec-metadata: track previous kernel chain Breno Leitao
2026-04-03 11:29   ` Pratyush Yadav [this message]
2026-03-16 11:54 ` [PATCH v9 6/6] kho: document kexec-metadata tracking feature Breno Leitao
2026-04-03 11:33 ` [PATCH v9 0/6] kho: history: track previous kernel version and kexec boot count Pratyush Yadav

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=2vxzika8cmez.fsf@kernel.org \
    --to=pratyush@kernel.org \
    --cc=graf@amazon.com \
    --cc=kernel-team@meta.com \
    --cc=kexec@lists.infradead.org \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pasha.tatashin@soleen.com \
    --cc=rppt@kernel.org \
    --cc=sj@kernel.org \
    --cc=usama.arif@linux.dev \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.