Re: [PATCH v1 08/36] mm/hugetlb: check for unreasonable folio sizes when registering hstate
Zi Yan <[email protected]>
| Newsgroups | com.zx2c4.lists.wireguard,dev.linux.lists.iommu,dev.linux.lists.virtualization,org.freedesktop.lists.dri-devel,org.freedesktop.lists.intel-gfx,org.infradead.lists.linux-arm-kernel,org.infradead.lists.linux-riscv,org.kernel.vger.io-uring,org.kernel.vger.kvm,org.kernel.vger.linux-crypto,org.kernel.vger.linux-ide,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.linux-mips,org.kernel.vger.linux-mmc,org.kernel.vger.linux-s390,org.kernel.vger.linux-scsi,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 27 Aug 2025, at 18:01, David Hildenbrand wrote: > Let's check that no hstate that corresponds to an unreasonable folio size > is registered by an architecture. If we were to succeed registering, we > could later try allocating an unsupported gigantic folio size. > > Further, let's add a BUILD_BUG_ON() for checking that HUGETLB_PAGE_ORDER > is sane at build time. As HUGETLB_PAGE_ORDER is dynamic on powerpc, we have > to use a BUILD_BUG_ON_INVALID() to make it compile. > > No existing kernel configuration should be able to trigger this check: > either SPARSEMEM without SPARSEMEM_VMEMMAP cannot be configured or > gigantic folios will not exceed a memory section (the case on sparse). > > Signed-off-by: David Hildenbrand <[email protected]> > --- > mm/hugetlb.c | 2 ++ > 1 file changed, 2 insertions(+) > LGTM. Reviewed-by: Zi Yan <[email protected]> -- Best Regards, Yan, Zi