[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aRSKrxfAb_GG_2Mw@kernel.org>
Date: Wed, 12 Nov 2025 15:25:03 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: pratyush@...nel.org, jasonmiu@...gle.com, graf@...zon.com,
dmatlack@...gle.com, rientjes@...gle.com, corbet@....net,
rdunlap@...radead.org, ilpo.jarvinen@...ux.intel.com,
kanie@...ux.alibaba.com, ojeda@...nel.org, aliceryhl@...gle.com,
masahiroy@...nel.org, akpm@...ux-foundation.org, tj@...nel.org,
yoann.congal@...le.fr, mmaurer@...gle.com, roman.gushchin@...ux.dev,
chenridong@...wei.com, axboe@...nel.dk, mark.rutland@....com,
jannh@...gle.com, vincent.guittot@...aro.org, hannes@...xchg.org,
dan.j.williams@...el.com, david@...hat.com,
joel.granados@...nel.org, rostedt@...dmis.org,
anna.schumaker@...cle.com, song@...nel.org, zhangguopeng@...inos.cn,
linux@...ssschuh.net, linux-kernel@...r.kernel.org,
linux-doc@...r.kernel.org, linux-mm@...ck.org,
gregkh@...uxfoundation.org, tglx@...utronix.de, mingo@...hat.com,
bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
hpa@...or.com, rafael@...nel.org, dakr@...nel.org,
bartosz.golaszewski@...aro.org, cw00.choi@...sung.com,
myungjoo.ham@...sung.com, yesanishhere@...il.com,
Jonathan.Cameron@...wei.com, quic_zijuhu@...cinc.com,
aleksander.lobakin@...el.com, ira.weiny@...el.com,
andriy.shevchenko@...ux.intel.com, leon@...nel.org, lukas@...ner.de,
bhelgaas@...gle.com, wagi@...nel.org, djeffery@...hat.com,
stuart.w.hayes@...il.com, ptyadav@...zon.de, lennart@...ttering.net,
brauner@...nel.org, linux-api@...r.kernel.org,
linux-fsdevel@...r.kernel.org, saeedm@...dia.com,
ajayachandra@...dia.com, jgg@...dia.com, parav@...dia.com,
leonro@...dia.com, witu@...dia.com, hughd@...gle.com,
skhawaja@...gle.com, chrisl@...nel.org
Subject: Re: [PATCH v5 02/22] liveupdate: luo_core: integrate with KHO
Hi Pasha,
On Tue, Nov 11, 2025 at 03:57:39PM -0500, Pasha Tatashin wrote:
> Hi Mike,
>
> Thank you for review, my comments below:
>
> > > This is why this call is placed first in reboot(), before any
> > > irreversible reboot notifiers or shutdown callbacks are performed. If
> > > an allocation problem occurs in KHO, the error is simply reported back
> > > to userspace, and the live update update is safely aborted.
The call to liveupdate_reboot() is just before kernel_kexec(). Why we don't
move it there?
And all the liveupdate_reboot() does if kho_finalize() fails it's massaging
the error value before returning it to userspace. Why kernel_kexec() can't
do the same?
> > This is fine. But what I don't like is that we can't use kho without
> > liveupdate. We are making debugfs optional, we have a way to call
>
> Yes you can: you can disable liveupdate (i.e. not supply liveupdate=1
> via kernel parameter) and use KHO the old way: drive it from the
> userspace. However, if liveupdate is enabled, liveupdate becomes the
> driver of KHO as unfortunately KHO has these weird states at the
> moment.
The "weird state" is the point where KHO builds its FDT. Replacing the
current memory tracker with one that does not require serialization won't
change it. We still need a way to tell KHO that "there won't be new nodes
in FDT, pack it".
> > kho_finalize() on the reboot path and it does not seem an issue to do it
> > even without liveupdate. But then we force kho_finalize() into
> > liveupdate_reboot() allowing weird configurations where kho is there but
> > it's unusable.
>
> What do you mean KHO is there but unusable, we should not have such a state...
If you compile a kernel with KEXEC_HANDOVER=y, KEXEC_HANDOVER_DEBUGFS=n and
LIVEUPDATE=n and boot with kho=1 there is nothing to trigger
kho_finalize().
> > What I'd like to see is that we can finalize KHO on kexec reboot path even
> > when liveupdate is not compiled and until then the patch that makes KHO
> > debugfs optional should not go further IMO.
> >
> > Another thing I didn't check in this series yet is how finalization driven
> > from debugfs interacts with liveupdate internal handling?
>
> I think what we can do is the following:
> - Remove "Kconfig: make debugfs optional" from this series, and
> instead make that change as part of stateless KHO work.
> - This will ensure that when liveupdate=0 always KHO finalize is fully
> support the old way.
> - When liveupdate=1 always disable KHO debugfs "finalize" API, and
> allow liveupdate to drive it automatically. It would add another
> liveupdate_enable() check to KHO, and is going to be removed as part
> of stateless KHO work.
KHO should not call into liveupdate. That's layering violation.
And "stateless KHO" does not really make it stateless, it only removes the
memory serialization from kho_finalize(), but it's still required to pack
the FDT.
I think we should allow kho finalization in some form from kernel_kexec().
When kho=1 and liveupdate=0, it will actually create the FDT if there was
no previous trigger from debugfs or it will continue with FDT created by
explicit request via debugfs.
When liveupdate=1, liveupdate_reboot() may call a function that actually
finalizes the state to allow safe rollback (although in the current patches
it does not seem necessary). And then kho_finalize() called from
kernel_kexec() will just continue with the state created by
liveupdate_reboot(). If we already finalized the kho state via debugfs,
liveupdate_reboot() can either error out or reset that state.
> Pasha
>
--
Sincerely yours,
Mike.
Powered by blists - more mailing lists