On Mon, Oct 20, 2025 at 9:46 AM Pasha Tatashin pasha.tatashin@soleen.com 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.
Forgot to add: The LUO preparation patches have been soaking in linux-next for some time now and are mostly reviewed. ...
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.