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

On Wed, Jul 08, 2026 at 04:11:04PM +0200, Pratyush Yadav wrote:
> 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.

I agree that this would increase the memory usage...

> 
> >
> > 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.
> 

Ack. My goal was to keep the KHO API opaque to prevent every driver
from having to peak into MM refcount internals. However, if the 
preference is for explicit intent, I can simply introduce something 
like a kho_restore_pages_unsplit() helper (or similar) that drivers 
can call specifically for high-order non-compound DMA buffers.

> >
> > 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?

Ack. I was trying to cover up an edge-case I guess but if we're simply
moving to an explicit restore API none on this would be needed.

Thanks,
Praan