From: Mike Rapoport <rppt@kernel.org>
To: Breno Leitao <leitao@debian.org>
Cc: Alexander Graf <graf@amazon.com>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
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, kernel-team@meta.com,
SeongJae Park <sj@kernel.org>
Subject: Re: [PATCH v4] kho: kexec-metadata: track previous kernel chain
Date: Sun, 25 Jan 2026 13:32:27 +0200 [thread overview]
Message-ID: <aXX_SxpI8Tuh6Q3V@kernel.org> (raw)
In-Reply-To: <aXILzST3NxyYXW1m@gmail.com>
On Thu, Jan 22, 2026 at 04:04:55AM -0800, Breno Leitao wrote:
> Hello Mike,
>
> On Thu, Jan 22, 2026 at 12:57:50PM +0200, Mike Rapoport wrote:
> > > +/**
> > > + * DOC: Kexec Metadata ABI
> > > + *
> >
> > It would be nice to link it from Documentation/ as well ;-)
>
> Ack! I am planning something as:
>
> commit 90e098ca0d611b44594f08e50ba1cff3c932dd2b
> Author: Breno Leitao <leitao@debian.org>
> Date: Thu Jan 22 03:47:23 2026 -0800
>
> kho: document kexec-metadata tracking feature
>
> Add documentation for the kexec-metadata feature that tracks the
> previous kernel version and kexec boot count across kexec reboots.
> This helps diagnose bugs that only reproduce when kexecing from
> specific kernel versions.
>
> Suggested-by: Mike Rapoport <rppt@kernel.org>
> Signed-off-by: Breno Leitao <leitao@debian.org>
>
> diff --git a/Documentation/admin-guide/mm/kho.rst b/Documentation/admin-guide/mm/kho.rst
> index 6dc18ed4b8861..1faf2c3ba4620 100644
> --- a/Documentation/admin-guide/mm/kho.rst
> +++ b/Documentation/admin-guide/mm/kho.rst
> @@ -113,3 +113,42 @@ stabilized.
> ``/sys/kernel/debug/kho/in/sub_fdts/``
> Similar to ``kho/out/sub_fdts/``, but contains sub FDT blobs
> of KHO producers passed from the old kernel.
> +
> +Kexec Metadata
> +==============
I'd move this section before "debugfs Interfaces", other than that LGTM.
> +
> +KHO automatically tracks metadata about the kexec chain, passing information
> +about the previous kernel to the next kernel. This feature helps diagnose
> +bugs that only reproduce when kexecing from specific kernel versions.
...
> > > static __init int kho_init(void)
> > > {
> > > const void *fdt = kho_get_fdt();
> > > @@ -1357,6 +1413,15 @@ static __init int kho_init(void)
> > > if (err)
> > > goto err_free_fdt;
> > >
> > > + if (fdt)
> > > + kho_process_kexec_metadata();
> >
> > Can't we move it into the existing if (fdt) below?
>
> Unfortunately, that won't work due to a data dependency between the two
> functions.
>
> kho_process_kexec_metadata() reads from the FDT subtree and populates kho_in:
>
> Basically:
>
> kho_in.kexec_count = metadata->kexec_count;
>
> While kho_populate_kexec_metadata() increments metadata->kexec_count:
>
> /* kho_in.kexec_count is set to 0 on cold boot */
> metadata->kexec_count = kho_in.kexec_count + 1;
>
> If kho_process_kexec_metadata() is moved after kho_populate_kexec_metadata(),
> the count would always increment from 0 to 1, ignoring whatever was passed in
> the FDT.
>
> Restructuring to call kho_in_debugfs_init() earlier also doesn't work:
>
>
> if (fdt) {
> kho_in_debugfs_init(&kho_in.dbg, fdt);
> kho_process_kexec_metadata();
> return 0;
> }
>
> /* Populate kexec metadata for the possible next kexec */
> err = kho_populate_kexec_metadata();
> if (err)
> pr_warn("failed to initialize kexec-metadata subtree: %d\n",
> err);
>
> This would return early without populating the kexec metadata for the next
> kexec, breaking the chain on KHO boots.
How about we rename kho_process_kexec_metadata() to
kho_retreive_kexec_metadata() and add kho_process_kexec_metadata() that
will first call _retrieve and then _populate? Something like
static int __init kho_process_kexec_metadata(const void *fdt)
{
int err;
if (fdt)
kho_retrieve_kexec_metadata();
/* Populate kexec metadata for the possible next kexec */
err = kho_populate_kexec_metadata();
if (err)
pr_warn("failed to initialize kexec-metadata subtree: %d\n",
err);
return err;
}
> --breno
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2026-01-25 11:32 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-21 14:50 Breno Leitao
2026-01-22 10:57 ` Mike Rapoport
2026-01-22 12:04 ` Breno Leitao
2026-01-25 11:32 ` Mike Rapoport [this message]
2026-01-26 10:51 ` Breno Leitao
2026-01-26 12:01 ` Breno Leitao
2026-01-26 13:28 ` Pratyush Yadav
2026-01-26 13:45 ` Pratyush Yadav
2026-01-26 13:47 ` Breno Leitao
2026-01-26 13:35 ` 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=aXX_SxpI8Tuh6Q3V@kernel.org \
--to=rppt@kernel.org \
--cc=clm@fb.com \
--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=pratyush@kernel.org \
--cc=riel@surriel.com \
--cc=rmikey@meta.com \
--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