On Mon, Oct 20, 2025 at 4:34 AM Mike Rapoport <[email protected]> wrote: > > On Sat, Oct 18, 2025 at 01:17:46PM -0400, Pasha Tatashin wrote: > > This series addresses comments and combines into one the two > > series [1] and [2], and adds review-bys. > > > > This series refactors the KHO framework to better support in-kernel > > users like the upcoming LUO. The current design, which relies on a > > notifier chain and debugfs for control, is too restrictive for direct > > programmatic use. > > > > The core of this rework is the removal of the notifier chain in favor of > > a direct registration API. This decouples clients from the shutdown-time > > finalization sequence, allowing them to manage their preserved state > > more flexibly and at any time. > > > > Also, this series fixes a memory corruption bug in KHO that occurs when > > KFENCE is enabled. > > > > The root cause is that KHO metadata, allocated via kzalloc(), can be > > randomly serviced by kfence_alloc(). When a kernel boots via KHO, the > > early memblock allocator is restricted to a "scratch area". This forces > > the KFENCE pool to be allocated within this scratch area, creating a > > conflict. If KHO metadata is subsequently placed in this pool, it gets > > corrupted during the next kexec operation. > > > > [1] > > https://lore.kernel.org/all/[email protected] > > [2] > > https://lore.kernel.org/all/[email protected] > > > > Mike Rapoport (Microsoft) (1): > > kho: drop notifiers > > > > Pasha Tatashin (9): > > kho: allow to drive kho from within kernel > > kho: make debugfs interface optional > > kho: add interfaces to unpreserve folios and page ranes > > kho: don't unpreserve memory during abort > > liveupdate: kho: move to kernel/liveupdate > > kho: move kho debugfs directory to liveupdate > > liveupdate: kho: warn and fail on metadata or preserved memory in scratch > > area > > liveupdate: kho: Increase metadata bitmap size to PAGE_SIZE > > liveupdate: kho: allocate metadata directly from the buddy allocator > > The fixes should go before the preparation for LUO or even better as a > separate series. > > I've reread the LUO preparation patches and I don't think they are useful > on their own. They introduce a couple of unused interfaces and I think it's > better to have them along with the rest of LUO patches.
Pulling them out to apply fixes separately feels counterproductive, especially since we agreed to add the new kexec_handover_debug.c file. The most straightforward path is to build on what's already in -next. Let's stick with the current approach. Thanks, Pasha > > -- > Sincerely yours, > Mike.
