[PATCH v1 04/13] kho: Verify deserialization status and fix FDT alignment access

[Pasha Tatashin]

> > This page is never freed, so adding it to zone managed pages or keeping it
> > reserved does not change anything.
>
> In practice, sure. I still don't see a good reason to _not_ initialize
> the page properly. It's not like it costs us much in terms of
> performance or code complexity.
>
> Since kho_restore_folio() makes sure the folio was _actually_ preserved
> from KHO, you have a safety check against previous kernel having a bug
> and not preserving the FDT properly. And I get that the FDT has already
> been used by this point, but at least you would have some known point to
> catch this.

The kho_alloc_preserve() API is different from kho_preserve_folio().
With kho_preserve_folio(), memory is allocated and some time later is
preserved, so there is a possibility for that memory to exist and be
used where it is not preserved, therefore it is a crucial step for
such memory to also do kho_restore_folio() before used. With
kho_alloc_preserve(), when the memory exists it is always preserved;
it is gurantee of this API. There is no reason to do
kho_restore_folio() on such memory at all. It can be released back to
the system via kho_free_restore()/kho_free_unpreserve().

Pasha

>
> [...]
>
> --
> Regards,
> Pratyush Yadav