All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Rapoport <rppt@kernel.org>
To: Chris Down <chris@chrisdown.name>
Cc: pasha.tatashin@soleen.com, pratyush@kernel.org, graf@amazon.com,
	kexec@lists.infradead.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH] kho: Prevent reuse of preserved pages after a reservation failure
Date: Wed, 11 Nov 2026 11:18:08 +0200	[thread overview]
Message-ID: <avQy0MUl6eOplwhh@kernel.org> (raw)
In-Reply-To: <avQka0wY-EdLkspv@chrisdown.name>

On Wed, Nov 11, 2026 at 12:16:43AM -0800, Chris Down wrote:
> Hi Mike,
> 
> Mike Rapoport writes:
> > On Tue, Nov 10, 2026 at 11:09:30PM -0800, Chris Down wrote:
> > > kho_preserved_memory_reserve() reserves each range of preserved memory
> > > in memblock and marks it noinit, but ignores both return values. Either
> > > can fail when memblock has to grow its reserved array and can't find
> > > room, which at this point in boot it may only take from KHO bootmem.
> > 
> > Is it an LLM analysis or you seen this happen?
> 
> Are those the only two options nowadays! :-) In this case it's just eyeballs.

Didn't think anybody still uses those :)
Kudos!
 
> I happened to notice this while preparing my KHO/LUO observability patchset
> and thought it made sense to send as a separate patch, since it doesn't
> depend on anything there.
> 
> It's probably realistically quite unlikely, I would think it would require a
> lot of fragmentation or a very small kho_bootmem=.

It's unlikely indeed and if that happens we'll panic on memory map
allocation anyway :)
 
> > > Dropping the handover at this point isn't safe either. reserve_mem=
> > > revives its regions from the handover before mm_core_init(), and
> > > relies on this walk to reserve them.
> > 
> > reserve_mem_kho_revive() can memblock_reserve() its memory itself and we
> > can carry on, can't we?
> 
> Thanks, that's better. I had thought carryong on wasn't possible because
> reserve_mem has already reserved its regions by the time we get to the walk,
> but actually you're right that there's no reason reserve_mem_kho_revive()
> can't just do it itself...
> 
> Looking at the code one thing we would likely trip over then is that
> kho_mem_retrieve()'s error path only clears fdt_phys, but not bootmem_phys.
> kho_init() then thinks that it's a cold boot and runs
> init_cma_reserved_pageblock() over the inherited bootmem which has already
> been handed to the buddy allocator, so this would need adjustment first.
> 
> So then, let me send v2 with reserve_mem_kho_revive() sorting out its own
> range, and making kho_init() skip the bootmem setup when the bootmem was
> inherited, if that sounds good?

Yeah, just keep them as two patches please :)
 
> Thanks!
> 
> Chris

-- 
Sincerely yours,
Mike.


  reply	other threads:[~2026-11-11  9:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-11  7:09 [PATCH] kho: Prevent reuse of preserved pages after a reservation failure Chris Down
2026-11-11  8:01 ` Mike Rapoport
2026-11-11  8:16   ` Chris Down
2026-11-11  9:18     ` Mike Rapoport [this message]
2026-11-11 21:28 ` Pasha Tatashin
2026-11-11 21:36   ` 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=avQy0MUl6eOplwhh@kernel.org \
    --to=rppt@kernel.org \
    --cc=chris@chrisdown.name \
    --cc=graf@amazon.com \
    --cc=kernel-team@meta.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 \
    /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.