Re: [PATCH] kho: Prevent reuse of preserved pages after a reservation failure

[Chris Down <chris@chrisdown.name>]

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.

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=.

>> 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?

Thanks!

Chris