[PATCH v1 08/36] mm/hugetlb: check for unreasonable folio sizes when registering hstate
David Hildenbrand
david at redhat.com
Fri Aug 29 03:07:44 PDT 2025
On 28.08.25 16:45, Lorenzo Stoakes wrote:
> On Thu, Aug 28, 2025 at 12:01:12AM +0200, 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).
>
> I am guessing it's implicit that MAX_FOLIO_ORDER <= section size?
Yes, we have a build-time bug that somewhere.
--
Cheers
David / dhildenb
More information about the linux-arm-kernel
mailing list