From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E02D144212A for ; Wed, 8 Jul 2026 14:11:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783519869; cv=none; b=UR7GxEeuO2f1XregBBo1vS6ofBtmemaPUqqNdOHfTdzTzZRXomU108UNK6HHydvX7ALa/+gFRdx2vZLXBuZIk2g033U7GywQZFrdqiXZ0gj+rS/YknkXDlrw4RuE8X9bSl4CUHVNGQQnXoUYL8WQ1hijiHEyODuMuzzx/n83RnU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783519869; c=relaxed/simple; bh=S1Fbd3EO4sydCdNoDUV11AE11q1QyzL7/ak4j2cBr/k=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=UOTkTw0X6aalmKgOiDNPMBYxuEiQSnchfgbiUE4uKY2DDJOLcoMWDQlodPzvo5BxZ3IOACGyEn3bqs5WkFeUjYy3DsNiCegXzrIZvgO907fYZoFnQY4cXgUyMT3LG8fnywwtdotuP2orleUBj5HGL/U/B36XSflV/UgYrkSpVmc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=CUQcU9G1; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="CUQcU9G1" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CC8FD1F00A3A; Wed, 8 Jul 2026 14:11:05 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783519867; bh=ts8+PPYmxoOpLLgVeTglSWE1PasRF+dUNUmJflgeGZM=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=CUQcU9G1jJ4xeYZiG3BZOH2n9CAq095h2H4KghWvlIVWxEl4bDX2Cs/id1+GyN5aq Q3Lkbj9ZFwkXKeIeQcwj7JqJQ2Nu3dDoPr91m0JOYW0zR5GgMpOiakj1U+3JrF8n5a 0bVwOrQhgjabZlvTy5q50RVhtvLcsIFaFor4qaz9ij1QPS3Vrk6jP7MBS7/zYlOjcn NmpRaiDVSZJvPXrciJ5a75LjjZPYpYsgPjFNy/VQoCFt9JAchFioDo/5OdPV7uODKY 24xjzqmhJCl1Mj7NTqHihjOMO3TAFSkAvUQtHFdhGi5uz+Aj0Mb9BZLNz6CgrkC9zh 5RmrRS35OcTsQ== From: Pratyush Yadav To: Pranjal Shrivastava Cc: Mike Rapoport , Pasha Tatashin , Pratyush Yadav , Alexander Graf , Samiullah Khawaja , David Matlack , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/4] kho: Support preserving unsplit high-order pages In-Reply-To: <20260703020832.1731864-1-praan@google.com> (Pranjal Shrivastava's message of "Fri, 3 Jul 2026 02:08:28 +0000") References: <20260703020832.1731864-1-praan@google.com> Date: Wed, 08 Jul 2026 16:11:04 +0200 Message-ID: <2vxz7bn5mv0n.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain 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. > > 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. > > 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? > > 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(). > > 3. The callers must ensure that the split_page() doesn't race with > kho_preserve_pages for consistency. > > 4. Folios are always implicitly considered of the CONTIG type > > Thanks, > Praan > > [1] https://lore.kernel.org/all/20260505002737.2213734-1-skhawaja@google.com/ > [2] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1370 > [3] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1027 > [4] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1034 > > Pranjal Shrivastava (4): > kho: Introduce infrastructure to track preserved page types > kho: Detect preserved page types > kho: Implement page-aware refcount restoration > kho: Introduce kho_split_preserved_pages() helper > > include/linux/kexec_handover.h | 7 ++ > include/linux/kho_radix_tree.h | 17 +++- > kernel/liveupdate/kexec_handover.c | 144 +++++++++++++++++++++-------- > 3 files changed, 124 insertions(+), 44 deletions(-) > > > base-commit: 87320be9f0d24fce67631b7eef919f0b79c3e45c -- Regards, Pratyush Yadav