Re: [PATCH v2 1/3] mm/huge_memory: Fix use of NULL folio in move_pages_huge_pmd()

[David Hildenbrand (Arm)]

On 3/2/26 18:43, Lorenzo Stoakes wrote:
> On Mon, Mar 02, 2026 at 06:35:46PM +0100, David Hildenbrand (Arm) wrote:
>>
>>>
>>> I prefer my version at [0].
>>>
>>> Cleaner to actually pull out the zero_folio into a local variable, and also we
>>> should mark it special to be consistent with other codepaths.
>>
>> I argued in v1 that we should handle it similar to an ordinary move
>> during mremap()->move_huge_pmd() and not split it over two patches.
>>
>> It's still split over two patches, which doesn't make sense.
> 
> Yes, let's not do that, I made the same comment.
> 
>>
>> https://lore.kernel.org/linux-mm/0b653dcd-842b-4360-bc1c-8fe779efbc23@xxxxxxxxxx/
>>
>> I don't think there is no need to get the folio involved at all if we
>> know that we have a well-prepared PMD (zero folio, makred as special).
>>
>> The less code we have that has to deal with setting PMDs special (and
>> possible messing it up), the better.
> 
> Yup I agree, I replied accordingly. That's a more elegant thing than duplicating
> huge zero installation code.
> 
> I had just assumed that there was _some reason_ why we wouldn't want to do that
> given the original patch from Suren didn't just do that, and for the sakes of a
> backport no need to think too deep on it.
> 
> But you're right I don't think there's any reason we need to diverge from what
> mremap() would do.
> 
> That does have:
> 
> 		if (vma_has_uffd_without_event_remap(vma))
> 			pmd = clear_uffd_wp_pmd(pmd);
> 
> Though rather than unconditonally invoking clear_uffd_wp_pmd().
> 
> Is that correct?

My conclusion was that UFFDIO_MOVE will never move uffd-wp information
(just like we currently don't do for any moved PTEs).

mremap() might sometimes. But it also effectively moves all (most) uffd
VMA properties, so it has slightly different semantics.

-- 
Cheers,

David