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

[Pranjal Shrivastava <praan@google.com>]

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

Ack, I'll add a new pair of preserve/unpreserve APIs for this and
mention it in the kdoc that the driver is responsible for handling
splitting preserved pages by unpreserving & represerving.

> 
> -- 
> Regards,
> Pratyush Yadav

Thanks
Praan