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

[Wei Yang]

On Thu, Jun 25, 2026 at 04:18:20PM +0000, Wei Yang wrote:
>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.
>

OK, I think I got the reason.

The error reported is against v3 [1], in which check_pmd() is just wrapped in
pmd_present().

But in v4, the new added check_pmd() usage is wrapped in
pmd_is_device_private_entry(), which is defined under
ARCH_ENABLE_THP_MIGRATION.

I have download 0day test suite and try to reproduce it with the instruction.
And prove v3 would trigger the error, while v4 doesn't.  PS: thanks Lorenzo's
suggestion to put into its own if branch, otherwise the code would be ugly.

Interesting lesson learned, thanks all for taking a look.

If so, I won't post a v5 for now.

[1]: https://lore.kernel.org/all/20260622130651.23359-1-richard.weiyang@xxxxxxxxx/
[2]: https://lore.kernel.org/all/20260624065353.1622-1-richard.weiyang@xxxxxxxxx/T/#u

-- 
Wei Yang
Help you, Help me