Re: [RFC PATCH 0/4] kho: Support preserving unsplit high-order pages

[Pratyush Yadav <pratyush@kernel.org>]

On Fri, Jul 03 2026, Pranjal Shrivastava wrote:

> This series is required for the ongoing effort to preserve DMA allocations
> across KHO [1]. It addresses a fundamental mismatch between the current KHO
> restoration logic and adds support for high-order buddy allocations.
>
> The Problem
> ===========
> The current KHO restore implementation treats all multi-page blocks as 
> split pages during restoration, i.e. kho_restore_pages() initializes 
> every 4KB page with a refcount of 1.
>
> However, many kernel subsystems, most notably the DMA allocator (via
> dma_alloc_coherent), frequently return high-order non-compound pages. 
> In this unsplit state, only the head page carries a refcount of 1, 
> while all tail pages have a reference count of 0.
>
> Consequently, when these contiguous but unsplit blocks are restored by 
> KHO in the new kernel, the forced refcount of 1 on tail pages causes some 
> trouble with the buddy allocator. Downstream of the eventual free path
> the __free_pages_prepare() [2] ends up calling page_expected_state() [3] 
> when is_check_pages_enabled() returns true (only when CONFIG_DEBUG_VM or
> debug_pagealloc=on).
>
> This detects the non-zero refcounts on tail pages [4] and incorrectly
> taints the kernel while leaking the pages in question.
>
> Proposed Solution
> =================
> This series introduces a "Page Type" field to the KHO ABI to track the
> refcount pattern of the preserved pages.
>
> 1. KHO detects the physical state (CONTIG vs SPLIT) during preservation
>    by peeking at the refcount of the second page in each buddy block.
>
> 2. The type bit is preserved in the high bits of the KHO radix tree key
>    (Bit 63) and stashed in page->private metadata during boot.

The KHO radix tree today only guarantees support for 53 bit wide keys.
Although in practice, on 4k pages the math works out to support 60 bit
wide keys in practice because we have 6 table levels.

Still, you can't preserve a key with the 63rd bit set. So how does your
code even work?

Also, if you do this, it comes with a side effect. It will increase the
memory usage of the radix tree, since now you have two branches of the
tree, one with the high bit set, and one without it. So that is more
intermediate table pages allocated.

>
> 3. kho_restore_page() applies the correct refcount pattern based on the
>    preserved metadata.

Why do you need to save the type of pages in KHO metadata? For example,
for pages or folios, we don't store any type information and leave it to
the caller choose the right API. So reserve-mem and kho vmalloc need
pages, they can call kho_{preserve,restore}_pages(), and memfd needs
folios so it can call kho_{preserve,restore}_folio(). The radix tree
itself does not hold the information. The caller knows what its memory
is supposed to be so it calls the right restore API.

So why can't we add a kho_{preserve,restore}_page_multi() (pick a better
name; we can argue about the naming later)? Then your driver knows it is
restoring DMA buffers so it can call kho_restore_page_multi(), and KHO
takes care of initializing the pages with the right refcounts.

You won't have to muck about with the ABI in that case.

>
> 4. A new helper, kho_split_preserved_pages(), is provided for subsystems
>    that may need to split memory after it has already been preserved.

Umm, that sounds scary... Why do you need to do that? What's the use
case? Why is the driver reconfiguring its memory after preservation? I
assume these are DMA buffers, so why do they suddenly look different?

And in either case, why does KHO need to do the split? Why can't the
driver unpreserve old preservation, then split the pages, and then
preserve the new ones?

>
> Considerations
> ==============
>
> 1. A primary goal of this approach is to prevent driver/subsystem code
>    from peeking into MM internals. Drivers should not need to understand
>    the distinction between head/tail pages or compound metadata. The KHO
>    core handles this internally.
>
> 2. To handle rare cases where a caller might wish to split a high-order 
>    block after preservation, we provide kho_split_preserved_pages().
>  
> 3. The callers must ensure that the split_page() doesn't race with
>    kho_preserve_pages for consistency.
>
> 4. Folios are always implicitly considered of the CONTIG type
>
> Thanks,
> Praan
>
> [1] https://lore.kernel.org/all/20260505002737.2213734-1-skhawaja@google.com/
> [2] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1370
> [3] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1027
> [4] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1034
>
> Pranjal Shrivastava (4):
>   kho: Introduce infrastructure to track preserved page types
>   kho: Detect preserved page types
>   kho: Implement page-aware refcount restoration
>   kho: Introduce kho_split_preserved_pages() helper
>
>  include/linux/kexec_handover.h     |   7 ++
>  include/linux/kho_radix_tree.h     |  17 +++-
>  kernel/liveupdate/kexec_handover.c | 144 +++++++++++++++++++++--------
>  3 files changed, 124 insertions(+), 44 deletions(-)
>
>
> base-commit: 87320be9f0d24fce67631b7eef919f0b79c3e45c

-- 
Regards,
Pratyush Yadav