Re: [PATCH 0/3] mm: handle device-private PMDs in walk callbacks

[Usama Arif]

On 07/07/2026 20:19, Joshua Hahn wrote:
> On Tue,  7 Jul 2026 06:45:06 -0700 Usama Arif <usama.arif@xxxxxxxxx> wrote:
> 
>> Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support
>> to PMD operations") a PMD may hold a device-private swap entry whenever
>> an HMM-based GPU driver migrates an anonymous THP folio to device memory
>> via migrate_vma_pages().
>>
>> pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true
>> for any non-present, non-none huge PMD), so several MM walk callbacks
>> that used to assume present THP or migration entry are now reachable with
>> a device-private PMD. The results range from a VM_BUG_ON() firing on debug
>> kernels, to an oops on a bogus vmemmap dereference, to silently isolating
>> an unrelated live folio from LRU in the aliasing case.
>>
>> The first 2 fixes were reported as pre-existing issues by sashiko in my
>> PMD swap entry series [1]. Hopefully sashiko won't point these out
>> in the next PMD swap entry series :)
> 
> Hello Usama,
> 
> Thank you for the fixes! I think all of them look good and they are fixes
> so please feel free to add my
> 
> Reviewed-by: Joshua Hahn <joshua.hahnjy@xxxxxxxxx>
> 
> One thing I wanted to maybe consider is for 1/3, whether it could be
> good to gate by !pmd_present() like the sites in 2/3 and 3/3, maybe
> that will be more robust in the future if there are other cases we
> should protect against (and the same as queue_folios_pte_range, which
> uses the !pte_present() check too).
> 
> For 2/3 and 3/3 we already have the !pmd_present() check, would it be
> worth considering just changing the VM_BUG_ON condition to include
> !pmd_is_device_private_entry()?
> 
> Just wanted to toss my 2c. Thanks again for the fixes Usama!
> Joshua
> 
Thanks for the reviews Joshua, I think they all made sense.
I have sent v2 [1] following your suggestions.

[1] https://lore.kernel.org/all/20260708122040.861335-1-usama.arif@xxxxxxxxx/