Re: [PATCH v7 02/22] liveupdate: luo_core: integrate with KHO

[Pasha Tatashin]

On Sun, Nov 23, 2025 at 9:17 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
>
> On Sun, Nov 23, 2025 at 07:03:19AM -0500, Pasha Tatashin wrote:
> > On Sun, Nov 23, 2025 at 6:27 AM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> > >
> > > On Sat, Nov 22, 2025 at 05:23:29PM -0500, Pasha Tatashin wrote:
> > > > Integrate the LUO with the KHO framework to enable passing LUO state
> > > > across a kexec reboot.
> > > >
> > > > This patch implements the lifecycle integration with KHO:
> > > >
> > > > 1. Incoming State: During early boot (`early_initcall`), LUO checks if
> > > >    KHO is active. If so, it retrieves the "LUO" subtree, verifies the
> > > >    "luo-v1" compatibility string, and reads the `liveupdate-number` to
> > > >    track the update count.
> > > >
> > > > 2. Outgoing State: During late initialization (`late_initcall`), LUO
> > > >    allocates a new FDT for the next kernel, populates it with the basic
> > > >    header (compatible string and incremented update number), and
> > > >    registers it with KHO (`kho_add_subtree`).
> > > >
> > > > 3. Finalization: The `liveupdate_reboot()` notifier is updated to invoke
> > > >    `kho_finalize()`. This ensures that all memory segments marked for
> > > >    preservation are properly serialized before the kexec jump.
> > > >
> > > > LUO now depends on `CONFIG_KEXEC_HANDOVER`.
> > > >
> > > > Signed-off-by: Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> > > > ---
> > > >  include/linux/kho/abi/luo.h      |  54 +++++++++++
> > > >  kernel/liveupdate/luo_core.c     | 154 ++++++++++++++++++++++++++++++-
> > > >  kernel/liveupdate/luo_internal.h |  22 +++++
> > > >  3 files changed, 229 insertions(+), 1 deletion(-)
> > > >  create mode 100644 include/linux/kho/abi/luo.h
> > > >  create mode 100644 kernel/liveupdate/luo_internal.h
> > > >
> > > > diff --git a/include/linux/kho/abi/luo.h b/include/linux/kho/abi/luo.h
> > > > new file mode 100644
> > > > index 000000000000..8523b3ff82d1
> > > > --- /dev/null
> > > > +++ b/include/linux/kho/abi/luo.h
> > > > @@ -0,0 +1,54 @@
> > > > +/* SPDX-License-Identifier: GPL-2.0 */
> > > > +
> > > > +/*
> > > > + * Copyright (c) 2025, Google LLC.
> > > > + * Pasha Tatashin <pasha.tatashin@xxxxxxxxxx>
> > > > + */
> > > > +
> > > > +/**
> > > > + * DOC: Live Update Orchestrator ABI
> > > > + *
> > > > + * This header defines the stable Application Binary Interface used by the
> > > > + * Live Update Orchestrator to pass state from a pre-update kernel to a
> > > > + * post-update kernel. The ABI is built upon the Kexec HandOver framework
> > > > + * and uses a Flattened Device Tree to describe the preserved data.
> > > > + *
> > > > + * This interface is a contract. Any modification to the FDT structure, node
> > > > + * properties, compatible strings, or the layout of the `__packed` serialization
> > > > + * structures defined here constitutes a breaking change. Such changes require
> > > > + * incrementing the version number in the relevant `_COMPATIBLE` string to
> > > > + * prevent a new kernel from misinterpreting data from an old kernel.
> > >
> > > From v6 thread:
> > >
> > > > > I'd add a sentence that stresses that ABI changes are possible as long they
> > > > > include changes to the FDT version.
> > > > > This is indeed implied by the last paragraph, but I think it's worth
> > > > > spelling it explicitly.
> > > > >
> > > > > Another thing that I think this should mention is that compatibility is
> > > > > only guaranteed for the kernels that use the same ABI version.
> > > >
> > > > Sure, I will add both.
> > >
> > > Looks like it fell between the cracks :/
> >
> > Hm, when I was updating the patches, I included the first part, and
> > then re-read the content, and I think it covers all points:
> >
> > 1. Changes are possible
> > This interface is a contract. Any modification to the FDT structure, node
> >  * properties, compatible strings, or the layout of the `__packed` serialization
> >  * structures defined here constitutes a breaking change. Such changes require
> >  * incrementing the version number in the relevant `_COMPATIBLE` string
> >
> > So, change as long as you update versioning number
> >
> > 2. Breaking if version is different:
> > to prevent a new kernel from misinterpreting data from an old kernel.
> >
> > So, the next kernel can interpret only if the version is the same.
> >
> > Which point do you think is not covered?
>
> As I said, it's covered, but it's implied. I'd prefer these stated
> explicitly.

Added, thanks.

>
> > > > +static int __init liveupdate_early_init(void)
> > > > +{
> > > > +     int err;
> > > > +
> > > > +     err = luo_early_startup();
> > > > +     if (err) {
> > > > +             luo_global.enabled = false;
> > > > +             luo_restore_fail("The incoming tree failed to initialize properly [%pe], disabling live update\n",
> > > > +                              ERR_PTR(err));
> > >
> > > What's wrong with a plain panic()?
> >
> > Jason suggested using the luo_restore_fail() function instead of
> > inserting panic() right in code somewhere in LUOv3 or earlier. It
> > helps avoid sprinkling panics in different places, and also in case if
> > we add the maintenance mode that we have discussed in LUOv6, we could
> > update this function as a place where that mode would be switched on.
>
> I'd agree if we were to have a bunch of panic()s sprinkled in the code.
> With a single one it's easier to parse panic() than lookup what
> luo_restore_fail() means.

The issue is that removing luo_restore_fail() removes the only
dependency on luo_internal.h in this patch. This would require me to
move the introduction of that header file to a later patch in the
series, which is difficult to handle via a simple fix-up.

Additionally, I still believe the abstraction is cleaner for future
extensibility (like the maintenance mode), even if it currently wraps
a single panic (which is actually a good thing, I have cleaned-up
things substantially to have  a single point  of panic since v2).
Therefore, it is my preference to keep it as is, unless a full series
is needed to be re-sent.

Pasha