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

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Mon, Mar 02, 2026 at 08:05:37PM +0100, David Hildenbrand (Arm) wrote:
> 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@kernel.org/
> >>
> >> 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.

Ack thanks!

>
> --
> Cheers,
>
> David

Cheers, Lorenzo