From: Breno Leitao <leitao@debian.org>
To: Pratyush Yadav <pratyush@kernel.org>
Cc: Alexander Graf <graf@amazon.com>, Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
linux-mm@kvack.org, usamaarif642@gmail.com,
SeongJae Park <sj@kernel.org>,
kernel-team@meta.com
Subject: Re: [PATCH v8 3/6] kho: persist blob size in KHO FDT
Date: Mon, 16 Mar 2026 04:09:43 -0700 [thread overview]
Message-ID: <abfkVOjq1ngZb-Nm@gmail.com> (raw)
In-Reply-To: <2vxzbjgsgk41.fsf@kernel.org>
On Fri, Mar 13, 2026 at 09:21:50AM +0000, Pratyush Yadav wrote:
> On Mon, Mar 09 2026, Breno Leitao wrote:
>
> > kho_add_subtree() accepts a size parameter but only forwards it to
> > debugfs. The size is not persisted in the KHO FDT, so it is lost across
> > kexec. This makes it impossible for the incoming kernel to determine the
> > blob size without understanding the blob format.
> >
> > Store the blob size as a "blob-size" property in the KHO FDT alongside
> > the "preserved-data" physical address. This allows the receiving kernel
> > to recover the size for any blob regardless of format.
> >
> > Also extend kho_retrieve_subtree() with an optional size output
> > parameter so callers can learn the blob size without needing to
> > understand the blob format. Update all callers to pass NULL for the
> > new parameter.
> >
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> > ---
> [...]
> > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> > index 54fe59fe43acd..1f22705d5d246 100644
> > --- a/kernel/liveupdate/kexec_handover.c
> > +++ b/kernel/liveupdate/kexec_handover.c
> > @@ -768,6 +768,7 @@ int kho_add_subtree(const char *name, void *blob, size_t size)
> > {
> > phys_addr_t phys = virt_to_phys(blob);
> > void *root_fdt = kho_out.fdt;
> > + u64 size_u64 = size;
> > int err = -ENOMEM;
> > int off, fdt_err;
> >
> > @@ -784,11 +785,16 @@ int kho_add_subtree(const char *name, void *blob, size_t size)
> > goto out_pack;
> > }
> >
> > - err = fdt_setprop(root_fdt, off, KHO_FDT_SUB_TREE_PROP_NAME,
> > + err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_PROP_NAME,
> > &phys, sizeof(phys));
> > if (err < 0)
> > goto out_pack;
> >
> > + err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_SIZE_PROP_NAME,
> > + &size_u64, sizeof(size_u64));
> > + if (err < 0)
> > + goto out_pack;
> > +
>
> I noticed that the error handling here is a bit broken. We open the
> subnode for the subtree, but then if we fail to add the "preserved-data"
> property, we don't remove the subnode. So the next kernel gets an
> invalid FDT (per KHO ABI) and might as well refuse to parse it.
>
> Similarly here, the FDT might also be missing the size and then the next
> kernel might reject the FDT.
>
> Also, we directly return the FDT error code to the caller, which
> wouldn't make sense since it probably expects -errno.
>
> Not something this patchset has to fix, but I am pointing this out in
> case someone (possibly also future me) is interested in fixing this up.
That is a good point, do you mean a fix like the following?
commit 633d0cb01ed959676b60de8b1851dad1757d8fe5
Author: Breno Leitao <leitao@debian.org>
Date: Mon Mar 16 04:03:51 2026 -0700
kho: fix error handling in kho_add_subtree()
Fix two error handling issues in kho_add_subtree():
1. If fdt_setprop() fails after the subnode has been created, the
subnode is not removed. This leaves an incomplete node in the FDT
(missing "preserved-data" or "blob-size" properties), which violates
the KHO ABI and may cause the next kernel to reject the FDT.
2. The fdt_setprop() return value (an FDT error code) is stored
directly in err and returned to the caller, which expects -errno.
Fix both by storing fdt_setprop() results in fdt_err, jumping to a new
out_del_node label that removes the subnode on failure, and only setting
err = 0 on the success path.
Signed-off-by: Breno Leitao <leitao@debian.org>
Suggested-by: Pratyush Yadav <pratyush@kernel.org>
diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index 62b1b8a9aa337..8d2d30119f6d4 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -787,19 +787,24 @@ int kho_add_subtree(const char *name, void *blob, size_t size)
goto out_pack;
}
- err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_PROP_NAME,
- &phys, sizeof(phys));
- if (err < 0)
- goto out_pack;
+ fdt_err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_PROP_NAME,
+ &phys, sizeof(phys));
+ if (fdt_err < 0)
+ goto out_del_node;
- err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_SIZE_PROP_NAME,
- &size_u64, sizeof(size_u64));
- if (err < 0)
- goto out_pack;
+ fdt_err = fdt_setprop(root_fdt, off, KHO_SUB_TREE_SIZE_PROP_NAME,
+ &size_u64, sizeof(size_u64));
+ if (fdt_err < 0)
+ goto out_del_node;
WARN_ON_ONCE(kho_debugfs_blob_add(&kho_out.dbg, name, blob,
size, false));
+ err = 0;
+ goto out_pack;
+
+out_del_node:
+ fdt_del_node(root_fdt, off);
out_pack:
fdt_pack(root_fdt);
Given this is not strictly related to this patchset, I am planning to
send this fix separately.
> > WARN_ON_ONCE(kho_debugfs_blob_add(&kho_out.dbg, name, blob,
> > size, false));
> >
> > @@ -817,7 +823,7 @@ void kho_remove_subtree(void *blob)
> > const u64 *val;
> > int len;
> >
> > - val = fdt_getprop(root_fdt, off, KHO_FDT_SUB_TREE_PROP_NAME, &len);
> > + val = fdt_getprop(root_fdt, off, KHO_SUB_TREE_PROP_NAME, &len);
> > if (!val || len != sizeof(phys_addr_t))
> > continue;
> >
> > @@ -1314,13 +1320,14 @@ EXPORT_SYMBOL_GPL(is_kho_boot);
> > * kho_retrieve_subtree - retrieve a preserved sub blob by its name.
> > * @name: the name of the sub blob passed to kho_add_subtree().
> > * @phys: if found, the physical address of the sub blob is stored in @phys.
> > + * @size: if not NULL and found, the size of the sub blob is stored in @size.
> > *
> > * Retrieve a preserved sub blob named @name and store its physical
> > - * address in @phys.
> > + * address in @phys and optionally its size in @size.
> > *
> > * Return: 0 on success, error code on failure
> > */
> > -int kho_retrieve_subtree(const char *name, phys_addr_t *phys)
> > +int kho_retrieve_subtree(const char *name, phys_addr_t *phys, size_t *size)
> > {
> > const void *fdt = kho_get_fdt();
> > const u64 *val;
> > @@ -1336,12 +1343,21 @@ int kho_retrieve_subtree(const char *name, phys_addr_t *phys)
> > if (offset < 0)
> > return -ENOENT;
> >
> > - val = fdt_getprop(fdt, offset, KHO_FDT_SUB_TREE_PROP_NAME, &len);
> > + val = fdt_getprop(fdt, offset, KHO_SUB_TREE_PROP_NAME, &len);
> > if (!val || len != sizeof(*val))
> > return -EINVAL;
> >
> > *phys = (phys_addr_t)*val;
> >
> > + if (size) {
> > + val = fdt_getprop(fdt, offset, KHO_SUB_TREE_SIZE_PROP_NAME,
> > + &len);
> > + if (val && len == sizeof(*val))
> > + *size = (size_t)*val;
> > + else
> > + *size = 0;
>
> If the size property is invalid, is it a good idea to ignore it? Should
> we instead consider the subnode to be broken and reject it entirely with
> an error message? Because if a caller expects a blob of 16 bytes but
> gets one with 0 bytes, it will likely error out anyway.
Ack, let me update this, then.
Thanks for the review,
--breno
next prev parent reply other threads:[~2026-03-16 11:10 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-09 13:41 [PATCH v8 0/6] kho: history: track previous kernel version and kexec boot count Breno Leitao
2026-03-09 13:41 ` [PATCH v8 1/6] kho: add size parameter to kho_add_subtree() Breno Leitao
2026-03-13 8:50 ` Pratyush Yadav
2026-03-09 13:41 ` [PATCH v8 2/6] kho: rename fdt parameter to blob in kho_add/remove_subtree() Breno Leitao
2026-03-13 8:52 ` Pratyush Yadav
2026-03-09 13:41 ` [PATCH v8 3/6] kho: persist blob size in KHO FDT Breno Leitao
2026-03-10 10:35 ` Mike Rapoport
2026-03-13 9:21 ` Pratyush Yadav
2026-03-16 11:09 ` Breno Leitao [this message]
2026-04-03 11:37 ` Pratyush Yadav
2026-03-09 13:41 ` [PATCH v8 4/6] kho: fix kho_in_debugfs_init() to handle non-FDT blobs Breno Leitao
2026-03-10 10:36 ` Mike Rapoport
2026-03-12 11:11 ` Breno Leitao
2026-03-12 16:17 ` Mike Rapoport
2026-03-13 9:23 ` Pratyush Yadav
2026-03-09 13:41 ` [PATCH v8 5/6] kho: kexec-metadata: track previous kernel chain Breno Leitao
2026-03-13 9:33 ` Pratyush Yadav
2026-04-09 10:13 ` Breno Leitao
2026-03-09 13:41 ` [PATCH v8 6/6] kho: document kexec-metadata tracking feature Breno Leitao
2026-03-13 9:34 ` Pratyush Yadav
2026-03-13 10:01 ` [PATCH v8 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=abfkVOjq1ngZb-Nm@gmail.com \
--to=leitao@debian.org \
--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=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.