Re: [PATCH v4 02/19] kho: block: Record the entry size in the block header

[Mike Rapoport <rppt@kernel.org>]

On Tue, Nov 10, 2026 at 08:10:32AM -0500, Pasha Tatashin wrote:
> On Tue Nov 10, 2026 at 12:01 AM EST, Tarun Sahu wrote:
> > Subsystems using the KHO Serialization Blocks framework currently do
> > not record the serialized entry size in the block header. The entry size
> > is only known to individual callers, which must track and store it in an
> > owning serialized data structure. If a newer source kernel adds fields
> > to an entry, the changed entry size breaks the stride when an older
> > target kernel iterates over blocks.
> >
> > Add an entry_size field to struct kho_block_header_ser. On the outgoing
> > side, record bs->entry_size into every block header during allocation.
> > During restoration, derive the entry stride directly from the block
> > header instead of relying on caller-supplied dimensions. The
> > kho_block_set_init() interface remains unchanged. A zero entry size,
> > or one that differs between blocks of a set, is rejected during
> > restoration.
> >
> > This change modifies the serialized layout of struct kho_block_header_ser
> > and shifts the offset of serialized entries within preserved blocks.
> > Bump KHO_FDT_COMPATIBLE from kho-v4 to kho-v5 so that pre-v5 and post-v5
> > kernels cleanly reject mismatched handover state during boot. Also
> > update the stale compatible string example in the documentation.
> >
> > Suggested-by: Pratyush Yadav <pratyush@kernel.org>
> > Signed-off-by: Tarun Sahu <tarunsahu@google.com>
> > ---
> >  include/linux/kho/abi/block.h          | 10 ++++----
> >  include/linux/kho/abi/kexec_handover.h |  6 ++---
> >  kernel/liveupdate/kho_block.c          | 32 +++++++++++++++++++++++---
> >  3 files changed, 38 insertions(+), 10 deletions(-)
> >
> > diff --git a/include/linux/kho/abi/block.h b/include/linux/kho/abi/block.h
> > index 36bdbaf9b3b8..a40b0906c821 100644
> > --- a/include/linux/kho/abi/block.h
> > +++ b/include/linux/kho/abi/block.h
> > @@ -40,9 +40,10 @@
> >  
> >  /**
> >   * struct kho_block_header_ser - Header for the serialized data block.
> > - * @next:  Physical address of the next struct kho_block_header_ser.
> > - * @count: The number of entries that immediately follow this header in the
> > - *         memory block.
> > + * @next:       Physical address of the next struct kho_block_header_ser.
> > + * @count:      The number of entries that immediately follow this header in the
> > + *              memory block.
> > + * @entry_size: The size in bytes of each serialized entry in the block.
> >   *
> >   * This structure is located at the beginning of a block of physical memory
> >   * preserved across a kexec. It provides the necessary metadata to interpret
> > @@ -51,9 +52,10 @@
> >  struct kho_block_header_ser {
> >  	u64 next;
> >  	u64 count;
> > +	u64 entry_size;
> >  };
> >  
> > -static_assert(sizeof(struct kho_block_header_ser) == 16);
> > +static_assert(sizeof(struct kho_block_header_ser) == 24);
> >  static_assert(!IS_ENABLED(CONFIG_64BIT) ||
> >  	      __alignof__(struct kho_block_header_ser) == 8);
> 
> The above change goes away once my comment on the previous patch 
> is addressed.
> 
> >  
> > diff --git a/include/linux/kho/abi/kexec_handover.h b/include/linux/kho/abi/kexec_handover.h
> > index 2f4fb9c63942..6f12f5037ea5 100644
> > --- a/include/linux/kho/abi/kexec_handover.h
> > +++ b/include/linux/kho/abi/kexec_handover.h
> > @@ -41,7 +41,7 @@
> >   *   restore the preserved data.::
> >   *
> >   *     / {
> > - *         compatible = "kho-v3";
> > + *         compatible = "kho-v5";
> >   *
> >   *         preserved-memory-map = <0x...>;
> >   *
> > @@ -62,7 +62,7 @@
> >   *     };
> >   *
> >   *   Root KHO Node (/):
> > - *     - compatible: "kho-v3"
> > + *     - compatible: "kho-v5"
> 
> These are just examples, don't update them.
> 
> >   *
> >   *       Identifies the overall KHO ABI version.
> >   *
> > @@ -90,7 +90,7 @@
> >   */
> >  
> >  /* The compatible string for the KHO FDT root node. */
> > -#define KHO_FDT_COMPATIBLE "kho-v4"
> > +#define KHO_FDT_COMPATIBLE "kho-v5"
> >  
> >  /* The FDT property for the preserved memory map. */
> >  #define KHO_FDT_MEMORY_MAP_PROP_NAME "preserved-memory-map"
> > diff --git a/kernel/liveupdate/kho_block.c b/kernel/liveupdate/kho_block.c
> > index 0d2a342ef422..9b148009085e 100644
> > --- a/kernel/liveupdate/kho_block.c
> > +++ b/kernel/liveupdate/kho_block.c
> > @@ -16,6 +16,12 @@
> >   * array of serialized entries. Multiple blocks are linked together via a
> >   * physical pointer in the header, forming a linked list that can be easily
> >   * traversed in both the current and the next kernel.
> > + *
> > + * Each block header also records the size of its entries. A newer kernel may
> 
> "newer kernel" does not make sense in the documentation comment, as any 
> kernel can do that. I would suggest "outgoing kernel." 

My understanding that here "newer" kernel refers to a newer kernel version
rather than incoming or outgoing. So the docs should say something like
"different kernel versions may have different size of the entry"

> By the way, in this series you use the terms "source" and "destination"
> kernel, whereas traditionally we have used "outgoing" and "incoming."
> While both conventions work, it would be preferable to maintain
> consistency.

-- 
Sincerely yours,
Mike.