Re: [PATCH v2] kho: init alloc tags when restoring pages from reserved memory

[Pratyush Yadav <pratyush@kernel.org>]

On Wed, Jan 14 2026, Suren Baghdasaryan wrote:

> On Wed, Jan 14, 2026 at 8:55 AM Pratyush Yadav <pratyush@kernel.org> wrote:
>>
>> Hi Ran,
>>
>> On Tue, Jan 13 2026, ranxiaokai627@163.com wrote:
>>
>> > From: Ran Xiaokai <ran.xiaokai@zte.com.cn>
>> >
>> > Memblock pages (including reserved memory) should have their allocation
>> > tags initialized to CODETAG_EMPTY via clear_page_tag_ref() before being
>> > released to the page allocator. When kho restores pages through
>> > kho_restore_page(), missing this call causes mismatched
>> > allocation/deallocation tracking and below warning message:
>> > alloc_tag was not set
>> > WARNING: include/linux/alloc_tag.h:164 at ___free_pages+0xb8/0x260, CPU#1: swapper/0/1
>> > RIP: 0010:___free_pages+0xb8/0x260
>> >  kho_restore_vmalloc+0x187/0x2e0
>> >  kho_test_init+0x3c4/0xa30
>> >  do_one_initcall+0x62/0x2b0
>> >  kernel_init_freeable+0x25b/0x480
>> >  kernel_init+0x1a/0x1c0
>> >  ret_from_fork+0x2d1/0x360
>> >
>> > Add missing clear_page_tag_ref() annotation in kho_restore_page() to
>> > fix this.
>> >
>> > Fixes: fc33e4b44b27 ("kexec: enable KHO support for memory preservation")
>> > Signed-off-by: Ran Xiaokai <ran.xiaokai@zte.com.cn>
>> > Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
>> > Reviewed-by: Suren Baghdasaryan <surenb@google.com>
>> > ---
>> >  kernel/liveupdate/kexec_handover.c | 1 +
>> >  1 file changed, 1 insertion(+)
>> >
>> > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
>> > index cd6b3fb9dcae..2d47f2c50bd8 100644
>> > --- a/kernel/liveupdate/kexec_handover.c
>> > +++ b/kernel/liveupdate/kexec_handover.c
>> > @@ -268,6 +268,7 @@ static struct page *kho_restore_page(phys_addr_t phys, bool is_folio)
>> >       else
>> >               kho_init_pages(page, nr_pages);
>> >
>> > +     clear_page_tag_ref(page);
>>
>> You are only clearing the tag for the head page. The tail pages are
>> still un-initialized. Is that intentional?
>
> In the case of a compound page we set the tag only on the head page,
> so this is correct.
>
>>
>> What about non-compound pages (the ones you get from
>> kho_restore_pages(), aka when is_folio is false)? Do we need to clear
>> the tag on all pages in that case?
>
> In the case of kho_restore_pages() we call split_page() which calls

Not since 7b71205ae112 ("kho: fix restoring of contiguous ranges of
order-0 pages"). That commit removed the split_pages() call and
open-coded the page initialization logic tailored for KHO.

So I think you do need to initialize the tags for kho_restore_pages().

I sent a patch [0] simplifying the page init logic a bit. I need to do a
v2 but it is a very simple change so I can get that done tomorrow. I
think it would be good to base your series on that since that would make
it easier for you to modify only the kho_restore_pages() path and the
end result would be cleaner.

[0] https://lore.kernel.org/linux-mm/20251223104448.195589-1-pratyush@kernel.org/

> pgalloc_tag_split() and that propagates the tag from the head page to
> all the tail pages being split from it. However now that I'm looking
> at it, I'm not sure pgalloc_tag_split() works correctly if the tag
> reference of the head page is CODETAG_EMPTY. In summary, this patch is
> fine but there might be a bug inside pgalloc_tag_split() if the tag
> reference is CODETAG_EMPTY.
>
> I'll analyze and reproduce that case. If it indeed has the issue I
> think it's easy to fix it by creating a specialized alloc_tag object
> with alloc_tag->ct=CODETAG_EMPTY and  make __pgalloc_tag_get() return
> it if the page's tag reference is CODETAG_EMPTY.
>
>>
>> >       adjust_managed_page_count(page, nr_pages);
>> >       return page;
>> >  }