]> git.ipfire.org Git - thirdparty/kernel/linux.git/commit
mm/hugetlb: cleanup hugetlb_folio_init_tail_vmemmap()
authorDavid Hildenbrand <david@redhat.com>
Mon, 1 Sep 2025 15:03:34 +0000 (17:03 +0200)
committerAndrew Morton <akpm@linux-foundation.org>
Sun, 21 Sep 2025 21:22:04 +0000 (14:22 -0700)
commit372c9b5491d2d8e85a8e1b8b74d4116654f5d816
treea4b30ddcf4eb06d085026a06a9fc5354b7cf5bd2
parent73b3294b1152e94c1971a735b8db8c7503fd97a1
mm/hugetlb: cleanup hugetlb_folio_init_tail_vmemmap()

We can now safely iterate over all pages in a folio, so no need for the
pfn_to_page().

Also, as we already force the refcount in __init_single_page() to 1
through init_page_count(), we can just set the refcount to 0 and avoid
page_ref_freeze() + VM_BUG_ON.  Likely, in the future, we would just want
to tell __init_single_page() to which value to initialize the refcount.

Further, adjust the comments to highlight that we are dealing with an
open-coded prep_compound_page() variant, and add another comment
explaining why we really need the __init_single_page() only on the tail
pages.

Note that the current code was likely problematic, but we never ran into
it: prep_compound_tail() would have been called with an offset that might
exceed a memory section, and prep_compound_tail() would have simply added
that offset to the page pointer -- which would not have done the right
thing on sparsemem without vmemmap.

Link: https://lkml.kernel.org/r/20250901150359.867252-14-david@redhat.com
Signed-off-by: David Hildenbrand <david@redhat.com>
Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org>
Reviewed-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Acked-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/hugetlb.c