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, kernel-team@meta.com,
SeongJae Park <sj@kernel.org>
Subject: Re: [PATCH v4] kho: kexec-metadata: track previous kernel chain
Date: Mon, 26 Jan 2026 04:01:11 -0800 [thread overview]
Message-ID: <aXdTEzsm88JKu9zY@gmail.com> (raw)
In-Reply-To: <20260121-kho-v4-1-5c8fe77b6804@debian.org>
On Wed, Jan 21, 2026 at 06:50:38AM -0800, Breno Leitao wrote:
> +static __init int kho_populate_kexec_metadata(void)
> +{
> + struct kho_kexec_metadata *metadata;
> + int err;
> +
> + metadata = kho_alloc_preserve(sizeof(*metadata));
> + if (IS_ERR(metadata))
> + return PTR_ERR(metadata);
> +
> + strscpy(metadata->previous_release, init_uts_ns.name.release,
> + sizeof(metadata->previous_release));
> + /* kho_in.kexec_count is set to 0 on cold boot */
> + metadata->kexec_count = kho_in.kexec_count + 1;
> +
> + err = kho_add_subtree(KHO_METADATA_NODE_NAME, metadata);
There is a hidden bug in here when CONFIG_KEXEC_HANDOVER_DEBUGFS is set.
kho_add_subtree() expects a fdt as the second argument, and we are
passing a pure C struct. That works fine, except for debugfs, which
does:
1. kho_add_subtree() calls kho_debugfs_fdt_add()
2. kho_debugfs_fdt_add() calls __kho_debugfs_fdt_add()
3. __kho_debugfs_fdt_add() executes fdt_totalsize(fdt)
The fdt_totalsize() macro reads bytes 4-7 of the input as a big-endian u32, and
this will hit struct kho_kexec_metadata, given I am passing a C struct instead
of a FDT.
struct kho_kexec_metadata {
char previous_release[__NEW_UTS_LEN + 1]; // 65 bytes
u32 kexec_count;
} __packed;
Bytes 4-7 would be characters from previous_release (e.g., "0-rc" from
"6.19.0-rc4..."). Interpreted as big-endian u32, this gives a garbage size
value.
The alternatives I see here are:
1) Come back to FDT instead of plain C struct, similarly to the previous
version [1]
2) Created some helpers to treat C struct fields specially just for this
feature, and we can do it later if we have more users.
3) Move this kexec_metadata to work on top of LUO (similarly to memfd), but
that would be an unnecessary dependency just to have this kexec_metadata.
That said, for the next version, I am coming back to to FDT.
Link: https://lore.kernel.org/all/20260108-kho-v3-0-b1d6b7a89342@debian.org/ [1]
--breno
next prev parent reply other threads:[~2026-01-26 12:01 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
2026-01-26 10:51 ` Breno Leitao
2026-01-26 12:01 ` Breno Leitao [this message]
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=aXdTEzsm88JKu9zY@gmail.com \
--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 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.