linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: linux-mm@kvack.org
Cc: Mike Rapoport <rppt@kernel.org>
Subject: [PATCH v2] mm: Fix memblock_free_late() when using deferred struct page
Date: Tue, 17 Feb 2026 19:28:12 +1100	[thread overview]
Message-ID: <bbffd0db46460cebd604f5c1e6668984fd4cc435.camel@kernel.crashing.org> (raw)
In-Reply-To: <ec2aaef14783869b3be6e3c253b2dcbf67dbc12a.camel@kernel.crashing.org>

We have two issues:

- One is we don't check for pfn_valid(). If this is called for
a page corresponding to a big enough memory hole that we don't have
allocated a corresponding sparsemem section for it, it will crash.

- Then, when using deferred struct page init, we can end up not
freeing the pages at all. This happens routinely with some of the
UEFI Boot Services memory, as soon as they fall above the threshold
of pages whose initialization is deferred.

We can very easily hit the !early_page_initialised() test in
memblock_free_pages() since the deferred initializer hasn't even
started yet. As a result we drop the pages on the floor.

Now, memblock_free_late() should only ever be called for pages that
are reserved, and thus for which the struct page has already been
initialized by memmap_init_reserved_pages().... as long as we check
for pfn_valid() as a big enough hole might cause entire sections of
the mem_map to not be allocated at all.

So it should be safe to just free them normally and ignore the deferred
initializer, which will skip over them as it skips over anything still
in the memblock reserved list.

This helps recover something like 140MB of RAM on EC2 t3a.nano instances
who only have 512MB to begin with (as to why UEFI uses that much, that's
a question for another day).

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---

v2. Reworked a bit to add the pfn_valid() check, remove the bogus memblock
access in debug mode, and add a test of PageReserved() for sanity.

We could separately do a patch forcing UEFI Boot Services into
memblock.memory but so far I haven't hit a case where that is necessary.

 mm/memblock.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/mm/memblock.c b/mm/memblock.c
index 905d06b16348a..71eb25b68851e 100644
--- a/mm/memblock.c
+++ b/mm/memblock.c
@@ -1770,9 +1770,14 @@ void __init memblock_free_late(phys_addr_t base, phys_addr_t size)
 	cursor = PFN_UP(base);
 	end = PFN_DOWN(base + size);
 
+	/* Only free pages that were reserved */
 	for (; cursor < end; cursor++) {
-		memblock_free_pages(pfn_to_page(cursor), cursor, 0);
-		totalram_pages_inc();
+		struct page *p;
+		if (!pfn_valid(cursor))
+			continue;
+		p = pfn_to_page(cursor);
+		if (!WARN_ON(!PageReserved(p)))
+			free_reserved_page(pfn_to_page(cursor));
 	}
 }
 
-- 
2.43.0




  parent reply	other threads:[~2026-02-17  8:28 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-03  8:02 [PATCH] " Benjamin Herrenschmidt
2026-02-03 18:40 ` Mike Rapoport
2026-02-03 19:53   ` Benjamin Herrenschmidt
2026-02-04  7:39     ` Mike Rapoport
2026-02-04  9:02       ` Benjamin Herrenschmidt
2026-02-06 10:33         ` Mike Rapoport
2026-02-10  1:04           ` Benjamin Herrenschmidt
2026-02-10  2:10             ` Benjamin Herrenschmidt
2026-02-10  6:17               ` Benjamin Herrenschmidt
2026-02-10  8:34                 ` Benjamin Herrenschmidt
2026-02-10 14:32                   ` Mike Rapoport
2026-02-10 23:23                     ` Benjamin Herrenschmidt
2026-02-11  5:20                       ` Mike Rapoport
2026-02-16  5:34                       ` Benjamin Herrenschmidt
2026-02-16  6:51                         ` Benjamin Herrenschmidt
2026-02-16  4:53                     ` Benjamin Herrenschmidt
2026-02-16 15:28                       ` Mike Rapoport
2026-02-16 10:36           ` Alexander Potapenko
2026-02-17  8:28 ` Benjamin Herrenschmidt [this message]
2026-02-17 12:32   ` [PATCH v2] " Mike Rapoport
2026-02-17 22:00     ` Benjamin Herrenschmidt
2026-02-17 21:47   ` Benjamin Herrenschmidt
2026-02-18  0:15     ` Benjamin Herrenschmidt
2026-02-18  8:05       ` Mike Rapoport
2026-02-19  2:48         ` Benjamin Herrenschmidt
2026-02-19 10:16           ` Mike Rapoport
2026-02-19 22:46             ` Benjamin Herrenschmidt
2026-02-20  4:57               ` Benjamin Herrenschmidt
2026-02-20  9:09                 ` Mike Rapoport
2026-02-20  9:00               ` Mike Rapoport
2026-02-20  5:12             ` Benjamin Herrenschmidt
2026-02-20  5:15             ` Benjamin Herrenschmidt
2026-02-20  5:47             ` Benjamin Herrenschmidt

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=bbffd0db46460cebd604f5c1e6668984fd4cc435.camel@kernel.crashing.org \
    --to=benh@kernel.crashing.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox