Re: [PATCH v8 1/4] mm: hugetlb_vmemmap: introduce CONFIG_HUGETLB_PAGE_HAS_OPTIMIZE_VMEMMAP

[Mike Kravetz <mike.kravetz@oracle.com>]

On 4/20/22 10:11, Masahiro Yamada wrote:
> On Wed, Apr 13, 2022 at 11:48 PM Muchun Song <songmuchun@bytedance.com> wrote:
>>
>> If the size of "struct page" is not the power of two but with the feature
>> of minimizing overhead of struct page associated with each HugeTLB is
>> enabled, then the vmemmap pages of HugeTLB will be corrupted after
>> remapping (panic is about to happen in theory).  But this only exists when
>> !CONFIG_MEMCG && !CONFIG_SLUB on x86_64.  However, it is not a conventional
>> configuration nowadays.  So it is not a real word issue, just the result
>> of a code review.  But we have to prevent anyone from configuring that
>> combined configurations.  In order to avoid many checks like "is_power_of_2
>> (sizeof(struct page))" through mm/hugetlb_vmemmap.c.  Introduce a new macro

Sorry for jumping in so late.  I am far from expert in Kconfig so did not pay
much attention to all those discussions.

Why not just add one (or a few) simple runtime checks for struct page not a
power of two before enabling hugetlb vmemmap optimization in the code?  Sure,
it would be ideal to never build/include the vmemmap optimization code if
this can be detected at config time.  However, it seems this is a very rare
combination and the checks for it at config time are very complex.

Would we really need many checks throughout the code as you mention above?
Or, do we only need to check or two before enabling
hugetlb_optimize_vmemmap_key?
-- 
Mike Kravetz