Re: [PATCH 06/11] mm/hugetlb: initialize all struct pages for bootmem hugepages

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mm/hugetlb: hugetlb_folio_init_vmemmap() wipes KMSAN metadata on
  head page
--

commit e4e80712cfb9bd9a2f1df0a9b2aae1625edb6829
Author: Muchun Song <muchun.song@linux.dev>

mm/hugetlb: initialize all struct pages for bootmem hugepages

This commit marks the entire boot-time gigantic hugepage as noinit in
memblock and initializes the head struct page alongside the tail struct
pages in hugetlb_folio_init_vmemmap().

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index ff6f837b6df01..d2aaad235458e 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3216,15 +3216,7 @@ static bool __init alloc_bootmem_huge_page(struct hstate *h, int nid)
>  		list_add_tail(&m->list, &huge_boot_pages[nid]);
>  		m->flags |= HUGE_BOOTMEM_ZONES_VALID;
>  		hugetlb_vmemmap_optimize_bootmem_page(pfn, huge_page_order(h));
> -		/*
> -		 * Only initialize the head struct page in memmap_init_reserved_pages,
> -		 * rest of the struct pages will be initialized by the HugeTLB
> -		 * subsystem itself.
> -		 * The head struct page is used to get folio information by the HugeTLB
> -		 * subsystem like zone id and node id.
> -		 */
> -		memblock_reserved_mark_noinit(__pa((void *)m + PAGE_SIZE),
> -				huge_page_size(h) - PAGE_SIZE);
> +		memblock_reserved_mark_noinit(__pa(m), huge_page_size(h));
>  	}
>  
>  	return true;
> @@ -3255,22 +3247,23 @@ static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio,
>  }
>  
>  static void __init hugetlb_folio_init_vmemmap(struct folio *folio,
> +					      unsigned long pfn,
>  					      struct hstate *h,
> +					      enum zone_type zone, int nid,
>  					      unsigned long nr_pages)
>  {
> -	int ret;
> +	struct page *head = &folio->page;
>  
>  	/*
>  	 * This is an open-coded prep_compound_page() whereby we avoid
>  	 * walking pages twice by initializing/preparing+freezing them in the
>  	 * same go.
>  	 */
> -	__folio_clear_reserved(folio);
> +	__init_single_page(head, pfn, zone, nid);

[Severity: Low]
Under CONFIG_KMSAN=y, does calling __init_single_page() on head here wipe
head->kmsan_shadow and head->kmsan_origin after kmsan_init_shadow() has
already populated them?

During mm_core_init(), kmsan_init_shadow() allocates and installs KMSAN
metadata for all memblock.reserved ranges, including MEMBLOCK_RSRV_NOINIT
regions:

mm/kmsan/init.c:kmsan_init_shadow() {
	...
	for_each_reserved_mem_range(loop, &p_start, &p_end)
		kmsan_record_future_shadow_range(phys_to_virt(p_start),
						 phys_to_virt(p_end));
	...
}

When page_alloc_init_late() later runs gather_bootmem_prealloc_node() ->
hugetlb_folio_init_vmemmap() -> __init_single_page() ->
memmap_init_page_common() -> mm_zero_struct_page(head) (and similarly via
memmap_init_compound_page_frozen() in commit "mm/hugetlb: use common
compound page initialization helper"), the entire struct page is zeroed,
leaking those shadow and origin pages and leaving head->kmsan_shadow and
head->kmsan_origin as NULL (extending the existing tail-page behavior in
hugetlb_folio_init_tail_vmemmap() to the head page).

If the bootmem gigantic folio is later freed to the buddy allocator at
runtime, kmsan_free_page() hits KMSAN_WARN_ON(true) and subsequent
allocations from the first pageblock cause a NULL pointer dereference in
kmsan_alloc_page().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261109095807.41547-1-songmuchun@bytedance.com?part=6