From: Pranjal Shrivastava <praan@google.com>
To: Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>
Cc: Alexander Graf <graf@amazon.com>,
Samiullah Khawaja <skhawaja@google.com>,
David Matlack <dmatlack@google.com>,
kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Pranjal Shrivastava <praan@google.com>
Subject: [RFC PATCH 3/4] kho: Implement page-aware refcount restoration
Date: Fri, 3 Jul 2026 02:08:31 +0000 [thread overview]
Message-ID: <20260703020832.1731864-4-praan@google.com> (raw)
In-Reply-To: <20260703020832.1731864-1-praan@google.com>
The KHO restoration logic currently forces a refcount of 1 on every
page of a multi-page block. While that is correct for split pages, it
violates the expectations of the buddy allocator for high-order
non-compound pages allocated by kernel user (like the DMA allocator),
where tail pages are expected to have a refcount of 0.
Update the restoration path to respect the preserved page type stored
in the page->private metadata. For KHO_PAGE_CONTIG blocks, only the
head page is given a reference count of 1. For KHO_PAGE_SPLIT blocks,
every page is given a reference count of 1.
Signed-off-by: Pranjal Shrivastava <praan@google.com>
---
kernel/liveupdate/kexec_handover.c | 35 +++++++++++++++++-------------
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
index d6e81f72fe5d..f6ca5e24c740 100644
--- a/kernel/liveupdate/kexec_handover.c
+++ b/kernel/liveupdate/kexec_handover.c
@@ -375,11 +375,18 @@ int kho_radix_walk_tree(struct kho_radix_tree *tree,
}
EXPORT_SYMBOL_GPL(kho_radix_walk_tree);
-/* For physically contiguous 0-order pages. */
-static void kho_init_pages(struct page *page, unsigned long nr_pages)
+/* For physically contiguous pages. */
+static void kho_restore_refcounts(struct page *page, unsigned long nr_pages,
+ enum kho_page_type type)
{
- for (unsigned long i = 0; i < nr_pages; i++) {
- set_page_count(page + i, 1);
+ /* Head page always gets refcount of 1. */
+ set_page_count(page, 1);
+ clear_page_tag_ref(page);
+
+ for (unsigned long i = 1; i < nr_pages; i++) {
+ unsigned int count = (type == KHO_PAGE_SPLIT) ? 1 : 0;
+
+ set_page_count(page + i, count);
/* Clear each page's codetag to avoid accounting mismatch. */
clear_page_tag_ref(page + i);
}
@@ -387,16 +394,7 @@ static void kho_init_pages(struct page *page, unsigned long nr_pages)
static void kho_init_folio(struct page *page, unsigned int order)
{
- unsigned long nr_pages = (1 << order);
-
- /* Head page gets refcount of 1. */
- set_page_count(page, 1);
- /* Clear head page's codetag to avoid accounting mismatch. */
- clear_page_tag_ref(page);
-
- /* For higher order folios, tail pages get a page count of zero. */
- for (unsigned long i = 1; i < nr_pages; i++)
- set_page_count(page + i, 0);
+ kho_restore_refcounts(page, 1 << order, KHO_PAGE_CONTIG);
if (order > 0)
prep_compound_page(page, order);
@@ -421,13 +419,20 @@ static struct page *kho_restore_page(phys_addr_t phys, bool is_folio)
return NULL;
nr_pages = (1 << info.order);
+ /*
+ * If we want to restore a folio, but the memory was split in the
+ * previous kernel, something is wrong.
+ */
+ if (WARN_ON_ONCE(is_folio && info.type == KHO_PAGE_SPLIT))
+ return NULL;
+
/* Clear private to make sure later restores on this page error out. */
page->private = 0;
if (is_folio)
kho_init_folio(page, info.order);
else
- kho_init_pages(page, nr_pages);
+ kho_restore_refcounts(page, nr_pages, info.type);
adjust_managed_page_count(page, nr_pages);
return page;
--
2.55.0.rc0.799.gd6f94ed593-goog
next prev parent reply other threads:[~2026-07-03 2:08 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-03 2:08 [RFC PATCH 0/4] kho: Support preserving unsplit high-order pages Pranjal Shrivastava
2026-07-03 2:08 ` [RFC PATCH 1/4] kho: Introduce infrastructure to track preserved page types Pranjal Shrivastava
2026-07-03 2:08 ` [RFC PATCH 2/4] kho: Detect " Pranjal Shrivastava
2026-07-03 2:08 ` Pranjal Shrivastava [this message]
2026-07-03 2:08 ` [RFC PATCH 4/4] kho: Introduce kho_split_preserved_pages() helper Pranjal Shrivastava
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260703020832.1731864-4-praan@google.com \
--to=praan@google.com \
--cc=dmatlack@google.com \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=skhawaja@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox