Re: [Patch mm-hotfixes v5] mm/page_vma_mapped: fix device-private PMD handling

[Lance Yang <lance.yang@linux.dev>]

On 2026/7/2 00:46, Klara Modin wrote:
[...]
>>>>
>>>> My only guess here would be that the compiler evaluates
>>>> !softleaf_is_migration(entry) to always be true and optimises away the
>>>> !check_pmd(softleaf_to_pfn(entry), pvmw) which is why this worked
>>>> before?
>>>
>>> Weird, we enter this path only with
>>>
>>> pmd_trans_huge(pmde) || pmd_is_migration_entry(pmde) ||
>>> pmd_is_device_private_entry(pmde)
>>>
>>> If any one of these would compile for !CONFIG_TRANSPARENT_HUGEPAGE that would be
>>> odd.
>>>
>>> pmd_is_device_private_entry() is hard-coded to false unless
>>> CONFIG_ARCH_ENABLE_THP_MIGRATION. Which is only selected with
>>> ARCH_ENABLE_THP_MIGRATION.
>>>
>>> pmd_trans_huge() as well.
>>>
>>> Maybe it's struggling with pmd_is_migration_entry() on some (older) compilers?
>>> (not innlining stuff and not properly optimizing it out).
> 
> It's a GCC 16 cross-compiler for armv6 so I wouldn't call it old :)
> 
>>>
>>> The whole conditional must be optimized out.
>>
>> Right. Kinda weird if compiler didn't fold
>>
>> pmd_trans_huge(pmde) || pmd_is_migration_entry(pmde) ||
>> pmd_is_device_private_entry(pmde)
>>
>> away here ...
>>
>>> We could check for IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) right at the start
>>> to make it easier for the compiler:
>>
>> +1, explicit THP guard should do the trick :)
>>
>>> if (IS_ENABLED(CONFIG_TRANSPARENT_HUGEPAGE)) &&
>>>     (pmd_trans_huge(pmde) || pmd_is_migration_entry(pmde) ||
>>>      pmd_is_device_private_entry(pmde))) {
>>>
>>>
>>
>> Klara, could you try with this change and see if it fixes the build?
>>
>> Thanks, Lance
> 
> This does indeed make it build.

Good to know, thanks for testing!