Re: [PATCH] mm/page_vma_mapped: guard check_pmd() with CONFIG_TRANSPARENT_HUGEPAGE

[Wei Yang <richard.weiyang@gmail.com>]

On Thu, Jun 25, 2026 at 04:30:33PM +0200, David Hildenbrand (Arm) wrote:
>On 6/25/26 16:02, Lorenzo Stoakes wrote:
>> On Thu, Jun 25, 2026 at 03:49:59PM +0200, David Hildenbrand (Arm) wrote:
>>> On 6/25/26 15:45, Lorenzo Stoakes wrote:
>>>>
>>>> Let me first say that I absolutely hate that we continue to support museum
>>>> piece architectures to the point that we have to make changes in core code
>>>> to accommodate them.
>>>
>>> I wonder why we shouldn't be able to trigger that on other archs with
>>> !CONFIG_TRANSPARENT_HUGEPAGE ?
>> 
>> I think this should just use CONFIG_PGTABLE_HAS_HUGE_LEAVES, since that's the
>> property that literally defines whether check_pmd() makes any sense.
>
>I stated earlier (when motivating a proper cleanup of this) that I detest
>pmd_trans_huge(). And yes, like I did in foliowalk, we should just check for
>IS_ENABLED(CONFIG_PGTABLE_HAS_HUGE_LEAVES) instead.
>
>Long story short: Wei's fix needs work, upstream is fine.
>

Ok, I didn't notice this is caused by my fix because pmd_trans_huge() == false
and check_pmd() skipped, but the newly add code doesn't. So I should merge this
with the pmd_is_device_private_entry() fix patch.

And should wrap it with CONFIG_PGTABLE_HAS_HUGE_LEAVES instead of
CONFIG_TRANSPARENT_HUGEPAGE.


But one more thing, I took a look into the robot test config and notice
ARCH_ENABLE_THP_MIGRATION is not defined either, which depends on
TRANSPARENT_HUGEPAGE (where pmd_trans_huge() depends). This means
pmd_is_device_private_entry() == false on this test environment.
And in theory it is false if TRANSPARENT_HUGEPAGE is not set.

So check_pmd() should be skipped too? Hope I am not too silly.

>-- 
>Cheers,
>
>David

-- 
Wei Yang
Help you, Help me