On Mon, Oct 20, 2025 at 09:46:17AM -0400, Pasha Tatashin wrote:
On Mon, Oct 20, 2025 at 4:34 AM Mike Rapoport rppt@kernel.org 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/20251007033100.836886-1-pasha.tatashin@soleen.co... [2] https://lore.kernel.org/all/20251015053121.3978358-1-pasha.tatashin@soleen.c...
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.
The fixes are 6.18 material, the LUO preparation is 6.19 material.
Thanks, Pasha
-- Sincerely yours, Mike.