Re: [PATCH] mm/page_vma_mapped: revalidate and do proper check before return device-private pmd

[Wei Yang]

On Mon, Jun 22, 2026 at 05:11:02PM +0100, Lorenzo Stoakes wrote:
>On Mon, Jun 22, 2026 at 02:21:02PM +0000, Wei Yang wrote:
>> On Mon, Jun 22, 2026 at 02:46:40PM +0100, Lorenzo Stoakes wrote:
>> >+cc Lance, linux-kernel
>> >
>> >Your subject line is 83 characters long and is way too detailed how about 'fix
>> >device-private PMD handling'?
>> >
>>
>> Got it.
>>
>> >You forgot to include linux-kernel@xxxxxxxxxxxxxxx on the mail, lore seems to be
>> >a bit broken atm but in general it's helpful to include that.
>>
>> Got it.
>>
>> So usually we send a patch to both linux-mm and linux-kernel? If so, I
>> remember is later actions.
>
>Yeah it's better for dealing with kvack going wrong etc. :)
>
>>
>> >
>> >Also is useful to make this [PATCH mm-hotfixes] to make it really clear it's
>> >intended as a hotfix.
>> >
>>
>> Got it.
>>
>> >Some commit msg language nits:
>> >
>> >On Mon, Jun 22, 2026 at 01:06:51PM +0000, Wei Yang wrote:
>> >> For pmd_trans_huge() and pmd_is_migration_entry(), we does following
>> >> before return the pmd entry:
>> >
>> >Sounds better as:
>> >
>> >	For PMD entries that satisfy pmd_trans_huge() or pmd_is_migration_entry(), we
>> >	perform the following actions:
>> >
>>
>> Sure.
>>
>> >>
>> >>   * re-validate pmd entry after PTL
>> >>   * check PVMW_MIGRATION
>> >>   * check_pmd()
>> >>   * handle on pte level if split under us
>> >>
>> >> But for device-private pmd, we just return after pmd_lock().
>> >
>> >->
>> >
>> >	However, for device-private PMD entries, we simply acquire the PMD lock
>> >	and return.
>> >
>>
>> Sure.
>>
>> >Also can you please give some justification here as to why all this also applies
>> >to device-private PMD? Right now it sounds hand wavey.
>> >
>>
>> I thought below paragraph explain it. Not sure what justification is preferred.
>
>Something about device private PMDs splitting the same way THP ones do, in the
>pmd_is_device_private_entry() branch of __split_huge_pmd_locked().
>

Hi, Lorenzo

Thanks for your detailed suggestions.

I tried to add the justification here, and the following is the commit log
after consolidate your suggestions.

    For PMD entries that satisfy pmd_trans_huge() or
    pmd_is_migration_entry(), we perform the following actions:
    
      * re-validate pmd entry after PTL
      * check PVMW_MIGRATION
      * check_pmd()
      * handle on pte level if split under us
    
    However, for device-private PMD entries, we simply acquire the PMD lock
    and return. This is not enough, as __split_huge_pmd_locked() would split
    a pmd device-private PMD under us just as it does for THP PMD.
    
    This is particularly problematic when PVMW_MIGRATION is set (meaning a
    migration entry is sought), as it causes a device-private PMD entry to
    be returned with a different data layout, causing memory corruption.

Just feel this is not that smooth. Would you mind taking another look to see
if I get your point correctly?

-- 
Wei Yang
Help you, Help me