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

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

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

-- 
Sincerely yours,
Mike.