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

[Pranjal Shrivastava <praan@google.com>]

On Tue, Jul 07, 2026 at 11:28:28AM +0300, Mike Rapoport 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.
> 
> This brings a broader question - what is the best way to deal with page
> metadata. This particular case requires only a single bit and luckily we
> have a few spare high bits in the radix tree key. But what if going
> forward we'll need more than a few bits? Do we need a parallel data
> structure for the page metadata? Or something in kho_radix_leaf in
> addition to the bitmap?
> 
> I'm not saying that a generic solution for page metadata must be a part
> of this series, but we definitely need to consider and better sooner
> than later.

Ack. I agree that regarding page metadata, we are limited by the 
available bits in the Radix key (and as discussed with Pratysh on the 
other thread it increases the memory usage too). I guess we need more
complex metadata in the future, a parallel data structure or expanding
struct kho_radix_leaf to include a metadata array alongside the bitmap
should be better in the long-ter I guess?

> 
> > 3. kho_restore_page() applies the correct refcount pattern based on the
> >    preserved metadata.
> > 
> > 4. A new helper, kho_split_preserved_pages(), is provided for subsystems
> >    that may need to split memory after it has already been preserved.
> > 
> > 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().
> 
> Do you have anything particular in mind?

Not really, I guess I was thinking of an edge case and attempted to
handle it this way. We could very well write this in the kdoc that the
caller who wants to do this must unpreserve first.

> 
> -- 
> Sincerely yours,
> Mike.
> 

Thanks,
Praan