On Mon, Oct 27, 2025 at 6:29 PM David Matlack dmatlack@google.com wrote:
On Mon, Oct 20, 2025 at 5:08 PM Pasha Tatashin pasha.tatashin@soleen.com wrote:
It is invalid for KHO metadata or preserved memory regions to be located within the KHO scratch area, as this area is overwritten when the next kernel is loaded, and used early in boot by the next kernel. This can lead to memory corruption.
Adds checks to kho_preserve_* and KHO's internal metadata allocators (xa_load_or_alloc, new_chunk) to verify that the physical address of the memory does not overlap with any defined scratch region. If an overlap is detected, the operation will fail and a WARN_ON is triggered. To avoid performance overhead in production kernels, these checks are enabled only when CONFIG_KEXEC_HANDOVER_DEBUG is selected.
How many scratch regions are there in practice? Checking unconditionally seems like a small price to pay to avoid possible memory corruption. Especially since most KHO preservation should happen while the VM is still running (so does not have to by hyper-optimized).
The debug option can be enabled on production system as well, we have some debug options enabled, but I do not see a reason to make this a fixed cost that can add up; the runtime cost scares me, as we might be using KHO preserve/unpreserve often once stateless KHO + slab preservation is implemented during some allocations paths. Let's keep it optional.
static void *xa_load_or_alloc(struct xarray *xa, unsigned long index, size_t sz) {
void *elm, *res;
void *res = xa_load(xa, index);
elm = xa_load(xa, index);if (elm)return elm;
if (res)return res;void *elm __free(kfree) = kzalloc(sz, GFP_KERNEL);nit: This breaks the local style of always declaring variables at the beginning of blocks.
I think this suggestion came from Mike, to me it looks alright, as it is only part of the clean-up path.
Pasha