All of lore.kernel.org
 help / color / mirror / Atom feed
From: Muchun Song <muchun.song@linux.dev>
To: sashiko-reviews@lists.linux.dev
Cc: Muchun Song <songmuchun@bytedance.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Oscar Salvador <osalvador@suse.de>,
	Mike Rapoport <rppt@kernel.org>, Lorenzo Stoakes <ljs@kernel.org>,
	"Liam R . Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>,
	James Houghton <jthoughton@google.com>,
	Lance Yang <lance.yang@linux.dev>, Qi Zheng <qi.zheng@linux.dev>,
	linux-mm@kvack.org
Subject: Re: [PATCH 06/11] mm/hugetlb: initialize all struct pages for bootmem hugepages
Date: Tue, 10 Nov 2026 11:23:51 +0800	[thread overview]
Message-ID: <2C89ED4A-9709-42AC-8DF2-3D7691475239@linux.dev> (raw)
In-Reply-To: <sashiko-outbox-204840@kernel.org>



> On Nov 9, 2026, at 18:43, sashiko-bot@kernel.org wrote:
> 
> 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?

This is a pre-existing KMSAN issue introduced by commit fde1c4ecf916 ("mm:
hugetlb: skip initialization of gigantic tail struct pages if freed by HVO").

That commit already reinitialized the tail struct pages after
kmsan_init_shadow(), potentially clearing their KMSAN metadata pointers. This
series extends the same behavior to the head page. I think the complete KMSAN
fix should be handled separately for both head and tail pages.

So, I will not fix it in this series.

Thanks.

> 
> 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



  reply	other threads:[~2026-11-10  3:24 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-09  9:57 [PATCH 00/11] mm: Unify memmap initialization for compound pages Muchun Song
2026-11-09  9:57 ` [PATCH 01/11] mm/mm_init: verify zones for template-initialized pages Muchun Song
2026-11-12 16:18   ` Mike Rapoport
2026-11-09  9:57 ` [PATCH 02/11] mm/mm_init: factor out common struct page initialization Muchun Song
2026-11-09 10:43   ` sashiko-bot
2026-11-10  3:08     ` Muchun Song
2026-11-09  9:57 ` [PATCH 03/11] mm/mm_init: simplify zone device " Muchun Song
2026-11-09  9:57 ` [PATCH 04/11] mm/mm_init: factor out frozen compound " Muchun Song
2026-11-09  9:58 ` [PATCH 05/11] mm/hugetlb: drop boot-time HVO handling for gigantic folios Muchun Song
2026-11-09 10:43   ` sashiko-bot
2026-11-10  3:16     ` Muchun Song
2026-11-09  9:58 ` [PATCH 06/11] mm/hugetlb: initialize all struct pages for bootmem hugepages Muchun Song
2026-11-09 10:43   ` sashiko-bot
2026-11-10  3:23     ` Muchun Song [this message]
2026-11-09  9:58 ` [PATCH 07/11] mm/hugetlb: use common compound page initialization helper Muchun Song
2026-11-09  9:58 ` [PATCH 08/11] mm/mm_init: make __init_single_page() static Muchun Song
2026-11-09  9:58 ` [PATCH 09/11] mm/cma: centralize CMA pageblock initialization Muchun Song
2026-11-09  9:58 ` [PATCH 10/11] mm/cma: localize init_cma_pageblock() to cma.c Muchun Song
2026-11-09  9:58 ` [PATCH 11/11] mm/mm_init: move pageblock migratetype init to memmap helpers Muchun Song
2026-11-09 10:43   ` sashiko-bot
2026-11-10  3:55     ` Muchun Song

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2C89ED4A-9709-42AC-8DF2-3D7691475239@linux.dev \
    --to=muchun.song@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=jthoughton@google.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=qi.zheng@linux.dev \
    --cc=rppt@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=songmuchun@bytedance.com \
    --cc=surenb@google.com \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.