[PATCH] kho: make sure folio being restored is actually from KHO
Pratyush Yadav
me at yadavpratyush.com
Wed Sep 10 08:52:04 PDT 2025
On Wed, Sep 10 2025, Matthew Wilcox wrote:
> On Wed, Sep 10, 2025 at 05:34:40PM +0200, Pratyush Yadav wrote:
>> +#define KHO_PAGE_MAGIC 0x4b484f50U /* ASCII for 'KHOP' */
>> +
>> +/*
>> + * KHO uses page->private, which is an unsigned long, to store page metadata.
>> + * Use it to store both the magic and the order.
>> + */
>> +union kho_page_info {
>> + unsigned long page_private;
>> + struct {
>> + unsigned int order;
>> + unsigned int magic;
>> + };
>
> KHO is only supported on 64-bit?
Yes. Currently only x86_64 and ARM64. It is mainly for hypervisor live
update so there isn't much reason to support it on 32-bit platforms.
>
>> @@ -210,16 +226,16 @@ static void kho_restore_page(struct page *page, unsigned int order)
>> struct folio *kho_restore_folio(phys_addr_t phys)
>> {
>> struct page *page = pfn_to_online_page(PHYS_PFN(phys));
>> - unsigned long order;
>> + union kho_page_info info;
>>
>> if (!page)
>> return NULL;
>>
>> - order = page->private;
>> - if (order > MAX_PAGE_ORDER)
>> + info.page_private = page->private;
>> + if (info.magic != KHO_PAGE_MAGIC || info.order > MAX_PAGE_ORDER)
>> return NULL;
>>
>> - kho_restore_page(page, order);
>> + kho_restore_page(page, info.order);
>> return page_folio(page);
>
> This all looks very confused. Before your patch as well as after it.
> I don't see anything in the current KHO code that requires the
> phys_addr_t to be order-aligned.
Right, good point. I can send that as a follow up patch. But I think
this patch stands on its own without that fix too.
--
Regards,
Pratyush Yadav
More information about the kexec
mailing list