From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Mike Rapoport <rppt@kernel.org>
Cc: linux-mm@kvack.org
Subject: Re: [PATCH v2] mm: Fix memblock_free_late() when using deferred struct page
Date: Thu, 19 Feb 2026 13:48:16 +1100 [thread overview]
Message-ID: <6453da0558ba20d5c87e730bdfedd47966977931.camel@kernel.crashing.org> (raw)
In-Reply-To: <aZVyxKVS8y-rqwrK@kernel.org>
On Wed, 2026-02-18 at 10:05 +0200, Mike Rapoport wrote:
> Apparently we do miss some piece of the puzzle, otherwise you'd see no
> crashes :)
>
> I think an easy and backportable fix would be to make
> efi_free_boot_services() an initcall, so that it will surely run after
> deferred pages are initialized.
> And since the boot services memory is not memblock_alloc()ed but rather
> memblock_reserve()ed, it should be freed with free_reserved_area().
>
> With the symptom fixed, we can audit memblock_free_late() and
> free_reserved_area() callers and see how to make this all less messy and
> more robust.
I will play around. The biggest issue I see with this is that
efi_free_boot_services() also manipulates the efi memmap, and that's
done without any locking whatsoever.
I'm semi tempted to split that part. We can unmap the boot services
from EFI memory in the current spot, and defer the actual freeing.
Cheers,
Ben.
next prev parent reply other threads:[~2026-02-19 2:48 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 ` [PATCH v2] " Benjamin Herrenschmidt
2026-02-17 12:32 ` 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 [this message]
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=6453da0558ba20d5c87e730bdfedd47966977931.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