From: Mike Rapoport <rppt@kernel.org>
To: Evangelos Petrongonas <epetron@amazon.de>
Cc: Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Alexander Graf <graf@amazon.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jason Miu <jasonmiu@google.com>,
linux-kernel@vger.kernel.org, kexec@lists.infradead.org,
linux-mm@kvack.org, nh-open-source@amazon.com
Subject: Re: [PATCH] kho: add support for deferred struct page init
Date: Tue, 16 Dec 2025 13:57:19 +0200 [thread overview]
Message-ID: <aUFJH9xzJXYOt_X8@kernel.org> (raw)
In-Reply-To: <20251216084913.86342-1-epetron@amazon.de>
Hi Evangelos,
On Tue, Dec 16, 2025 at 08:49:12AM +0000, Evangelos Petrongonas wrote:
> When `CONFIG_DEFERRED_STRUCT_PAGE_INIT` is enabled, struct page
No need for markup formatting in the changelog.
> initialization is deferred to parallel kthreads that run later
> in the boot process.
>
> During KHO restoration, `deserialize_bitmap()` writes metadata for
> each preserved memory region. However, if the struct page has not been
> initialized, this write targets uninitialized memory, potentially
> leading to errors like:
> ```
> BUG: unable to handle page fault for address: ...
> ```
>
> Fix this by introducing `kho_get_preserved_page()`, which ensures
> all struct pages in a preserved region are initialized by calling
> `init_deferred_page()` which is a no-op when deferred init is disabled
> or when the struct page is already initialized.
>
> Fixes: 8b66ed2c3f42 ("kho: mm: don't allow deferred struct page with KHO")
> Signed-off-by: Evangelos Petrongonas <epetron@amazon.de>
> ---
...
> +static struct page *__init kho_get_preserved_page(phys_addr_t phys,
> + unsigned int order)
> +{
> + unsigned long pfn = PHYS_PFN(phys);
> + int nid = early_pfn_to_nid(pfn);
> +
> + for (int i = 0; i < (1 << order); i++)
> + init_deferred_page(pfn + i, nid);
This will skip pages below node->first_deferred_pfn, we need to use
__init_page_from_nid() here.
> +
> + return pfn_to_page(pfn);
> +}
> +
> static void __init deserialize_bitmap(unsigned int order,
> struct khoser_mem_bitmap_ptr *elm)
> {
> @@ -449,7 +466,7 @@ static void __init deserialize_bitmap(unsigned int order,
> int sz = 1 << (order + PAGE_SHIFT);
> phys_addr_t phys =
> elm->phys_start + (bit << (order + PAGE_SHIFT));
> - struct page *page = phys_to_page(phys);
> + struct page *page = kho_get_preserved_page(phys, order);
I think it's better to initialize deferred struct pages later in
kho_restore_page. deserialize_bitmap() runs before SMP and it already does
heavy lifting of memblock_reserve()s. Delaying struct page initialization
until restore makes it at least run in parallel with other initialization
tasks.
I started to work on this just before plumbers and I have something
untested here:
https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git/log/?h=kho/deferred-page/v0.1
> union kho_page_info info;
>
> memblock_reserve(phys, sz);
> --
> 2.43.0
>
>
>
>
> Amazon Web Services Development Center Germany GmbH
> Tamara-Danz-Str. 13
> 10243 Berlin
> Geschaeftsfuehrung: Christof Hellmis, Andreas Stieger
> Eingetragen am Amtsgericht Charlottenburg unter HRB 257764 B
> Sitz: Berlin
> Ust-ID: DE 365 538 597
>
--
Sincerely yours,
Mike.
next prev parent reply other threads:[~2025-12-16 11:57 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-16 8:49 [PATCH] kho: add support for deferred struct page init Evangelos Petrongonas
2025-12-16 10:53 ` Pasha Tatashin
2025-12-16 11:57 ` Mike Rapoport [this message]
2025-12-16 14:26 ` Evangelos Petrongonas
2025-12-16 15:05 ` Pasha Tatashin
2025-12-16 15:19 ` Mike Rapoport
2025-12-16 15:36 ` Pasha Tatashin
2025-12-16 15:51 ` Pasha Tatashin
2025-12-20 2:27 ` Pratyush Yadav
2025-12-19 9:19 ` Mike Rapoport
2025-12-19 16:28 ` Pasha Tatashin
2025-12-20 3:20 ` Pratyush Yadav
2025-12-20 14:49 ` Pasha Tatashin
2025-12-22 15:33 ` Pratyush Yadav
2025-12-22 15:55 ` Pasha Tatashin
2025-12-22 16:24 ` Pratyush Yadav
2025-12-23 17:37 ` Pasha Tatashin
2025-12-29 21:03 ` Pratyush Yadav
2025-12-30 16:05 ` Pasha Tatashin
2025-12-30 16:16 ` Mike Rapoport
2025-12-30 16:18 ` Pasha Tatashin
2025-12-30 17:18 ` Mike Rapoport
2025-12-30 18:21 ` Pasha Tatashin
2025-12-31 9:46 ` Mike Rapoport
2026-01-02 14:24 ` Pratyush Yadav
2026-01-02 14:05 ` Pratyush Yadav
2025-12-30 16:14 ` Mike Rapoport
2026-01-03 5:23 ` Jason Miu
2026-02-04 18:44 ` Mike Rapoport
2026-02-05 9:39 ` Evangelos Petrongonas
-- strict thread matches above, loose matches on Subject: below --
2025-12-24 7:34 Fadouse
2025-12-29 21:09 ` Pratyush Yadav
2025-12-30 15:05 ` Pasha Tatashin
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=aUFJH9xzJXYOt_X8@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=epetron@amazon.de \
--cc=graf@amazon.com \
--cc=jasonmiu@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=nh-open-source@amazon.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.