All of lore.kernel.org
 help / color / mirror / Atom feed
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.


  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 [PATCH v4] kho: kexec-metadata: track previous kernel chain 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 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.