From: sashiko-bot@kernel.org
To: "Li Zhe" <lizhe.67@bytedance.com>,
akpm@linux-foundation.org, apopple@nvidia.com,
balbirs@nvidia.com, david@kernel.org, muchun.song@linux.dev,
osalvador@suse.de, rppt@kernel.org
Cc: linux-mm@kvack.org
Subject: Re: [PATCH v2 2/2] mm/hugetlb: optimize bootmem hugepage tail vmemmap init
Date: Tue, 10 Nov 2026 13:35:36 +0000 [thread overview]
Message-ID: <sashiko-outbox-207133@kernel.org> (raw)
In-Reply-To: <20261110114859.76343-3-lizhe.67@bytedance.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [High] mm/hugetlb: out-of-bounds write in
hugetlb_folio_init_tail_vmemmap()
--
commit 5be89b38412d58045fd600596787f54c7559d32c
Author: Li Zhe <lizhe.67@bytedance.com>
mm/hugetlb: optimize bootmem hugepage tail vmemmap init
This commit optimizes bootmem hugepage tail struct page initialization by
seeding a template from the first tail page and initializing the remaining
tail pages via memmap_init_page_from_template().
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index cb2de24affdc4..6ae5d2679e3aa 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3239,6 +3239,7 @@ static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio,
> enum zone_type zone = folio_zonenum(folio);
> int nid = folio_nid(folio);
> struct page *page = folio_page(folio, start_page_number);
> + struct page template;
> unsigned long head_pfn = folio_pfn(folio);
> unsigned long pfn, end_pfn = head_pfn + end_page_number;
> unsigned int order = huge_page_order(h);
> @@ -3247,11 +3248,20 @@ static void __init hugetlb_folio_init_tail_vmemmap(struct folio *folio,
> * As we marked all tail pages with memblock_reserved_mark_noinit(),
> * we must initialize them ourselves here.
> */
> - for (pfn = head_pfn + start_page_number; pfn < end_pfn; page++, pfn++) {
> - __init_single_page(page, pfn, zone, nid);
> - prep_compound_tail(page, &folio->page, order);
> - set_page_count(page, 0);
> - }
> + pfn = head_pfn + start_page_number;
> +
> + /*
> + * Seed a template from the first real tail page and refresh only
> + * PFN-dependent fields before copying it.
> + */
> + __init_single_page(page, pfn, zone, nid);
> + prep_compound_tail(page, &folio->page, order);
> + set_page_count(page, 0);
> + memcpy(&template, page, sizeof(template));
> +
> + for (pfn++; pfn < end_pfn; pfn++)
> + memmap_init_page_from_template(pfn_to_page(pfn), pfn, zone,
> + &template);
[Severity: High]
Can peeling the first iteration out of the loop overwrite the struct page
past the end of folio when start_page_number >= end_page_number?
Previously, the loop was a no-op when pfn >= end_pfn. Now, when HVO does
not optimize a gigantic folio, prep_and_add_bootmem_folios() calls
hugetlb_folio_init_tail_vmemmap(folio, h,
VMEMMAP_OPTIMIZATION_NR_STRUCT_PAGES, pages_per_huge_page(h)) after
gather_bootmem_prealloc_node() has already initialized the first
VMEMMAP_OPTIMIZATION_NR_STRUCT_PAGES pages.
On configurations where a gigantic page has pages_per_huge_page(h) <=
VMEMMAP_OPTIMIZATION_NR_STRUCT_PAGES (for example, powerpc
mpc885_ads_defconfig with 16 KiB pages, MAX_PAGE_ORDER == 8, and 8 MiB
gigantic hugepages of order 9, where both values are 512), this
unconditionally initializes folio_page(folio, start_page_number) and marks
the adjacent physical page's struct page as a compound tail of folio,
corrupting mem_map.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261110114859.76343-1-lizhe.67@bytedance.com?part=2
next prev parent reply other threads:[~2026-11-10 13:35 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 11:48 [PATCH v2 0/2] mm: optimize HugeTLB bootmem hugepage init Li Zhe
2026-11-10 11:48 ` [PATCH v2 1/2] mm/mm_init: factor out memmap_init_page_from_template() Li Zhe
2026-11-11 7:58 ` Muchun Song
2026-11-10 11:48 ` [PATCH v2 2/2] mm/hugetlb: optimize bootmem hugepage tail vmemmap init Li Zhe
2026-11-10 13:35 ` sashiko-bot [this message]
2026-11-11 3:14 ` Li Zhe
2026-11-11 5:28 ` Muchun Song
2026-11-11 7:57 ` Li Zhe
2026-11-11 8:16 ` Mike Rapoport
2026-11-11 8:21 ` Muchun Song
2026-11-11 8:14 ` Mike Rapoport
2026-11-11 8:12 ` [PATCH v2 0/2] mm: optimize HugeTLB bootmem hugepage init Mike Rapoport
2026-11-11 11:24 ` Li Zhe
2026-11-11 11:37 ` 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=sashiko-outbox-207133@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=balbirs@nvidia.com \
--cc=david@kernel.org \
--cc=linux-mm@kvack.org \
--cc=lizhe.67@bytedance.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=rppt@kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/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.