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

[Pratyush Yadav <pratyush@kernel.org>]

On Wed, Jul 08 2026, Pranjal Shrivastava wrote:

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

Even with an explicit restore API, I'd say it would be a bad idea to
preserve using one API and restore using another. The driver really
should be unpreserving and represerving. And even that if it really has
to.

-- 
Regards,
Pratyush Yadav