Re: [PATCH] kho: add support for deferred struct page init

[Pratyush Yadav <pratyush@kernel.org>]

On Tue, Dec 30 2025, Pasha Tatashin wrote:

> On Mon, Dec 29, 2025 at 4:03 PM Pratyush Yadav <pratyush@kernel.org> wrote:
>>
>> On Tue, Dec 23 2025, Pasha Tatashin wrote:
[...]
>> >
>> > I kind of do not like relying on magic to decide whether to initialize
>> > the struct page. I would prefer to avoid this magic marker altogether:
>> > i.e. struct page is either initialized or not, not halfway
>> > initialized, etc.
>>
>> The magic is purely sanity checking. It is not used to decide anything
>> other than to make sure this is actually a KHO page. I don't intend to
>> change that. My point is, if we make sure the KHO pages are properly
>> initialized during MM init, then restoring can actually be a very cheap
>> operation, where you only do the sanity checking. You can even put the
>> magic check behind CONFIG_KEXEC_HANDOVER_DEBUG if you want, but I think
>> it is useful enough to keep in production systems too.
>
> It is part of a critical hotpath during blackout, should really be
> behind CONFIG_KEXEC_HANDOVER_DEBUG
>
>> > Magic is not reliable. During machine reset in many firmware
>> > implementations, and in every kexec reboot, memory is not zeroed. The
>> > kernel usually allocates vmemmap using exactly the same pages, so
>> > there is just too high a chance of getting magic values accidentally
>> > inherited from the previous boot.
>>
>> I don't think that can happen. All the pages are zeroed when
>> initialized, which will clear the magic. We should only be setting the
>> magic on an initialized struct page.
>
> This can happen due to bugs when we use a partially initialized
> "struct page", something that Mike have been looking to do. So, pass
> some information in a struct page before it is fully initialized.

The magic is checked at restore time though, and by then all non-KHO
pages should be properly initialized and have their magic cleared.

Also, the magic is cleared by kho_restore_folio(), so this can only ever
happen for pages that were preserved but not restored in the previous
boot. I don't think that is a common use case in the first place.

[...]

-- 
Regards,
Pratyush Yadav