public inbox for linux-mm@kvack.org
 help / color / mirror / Atom feed
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


  reply	other threads:[~2026-03-16 11:09 UTC|newest]

Thread overview: 19+ 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-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-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox