Re: [PATCH v3 01/16] mm: correctly handle UFFD PTE markers
From: Lorenzo Stoakes
Date: Tue Nov 11 2025 - 04:57:28 EST
On Tue, Nov 11, 2025 at 11:39:43AM +0200, Mike Rapoport wrote:
> On Mon, Nov 10, 2025 at 10:21:19PM +0000, Lorenzo Stoakes wrote:
> > PTE markers were previously only concerned with UFFD-specific logic - that
> > is, PTE entries with the UFFD WP marker set or those marked via
> > UFFDIO_POISON.
> >
> > However since the introduction of guard markers in commit
> > 7c53dfbdb024 ("mm: add PTE_MARKER_GUARD PTE marker"), this has no longer
> > been the case.
> >
> > Issues have been avoided as guard regions are not permitted in conjunction
> > with UFFD, but it still leaves very confusing logic in place, most notably
> > the misleading and poorly named pte_none_mostly() and
> > huge_pte_none_mostly().
> >
> > This predicate returns true for PTE entries that ought to be treated as
> > none, but only in certain circumstances, and on the assumption we are
> > dealing with H/W poison markers or UFFD WP markers.
> >
> > This patch removes these functions and makes each invocation of these
> > functions instead explicitly check what it needs to check.
> >
> > As part of this effort it introduces is_uffd_pte_marker() to explicitly
> > determine if a marker in fact is used as part of UFFD or not.
> >
> > In the HMM logic we note that the only time we would need to check for a
> > fault is in the case of a UFFD WP marker, otherwise we simply encounter a
> > fault error (VM_FAULT_HWPOISON for H/W poisoned marker, VM_FAULT_SIGSEGV
> > for a guard marker), so only check for the UFFD WP case.
> >
> > While we're here we also refactor code to make it easier to understand.
> >
> > Reviewed-by: Vlastimil Babka <vbabka@xxxxxxx>
> > Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx>
>
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
Thanks!
>
> with a small nit below
>
> > ---
> >
> > - ret = false;
> > + /*
> > + * A race could arise which would result in a softleaf entry such a
>
> ^ such as
Oops, can fix up on next respin :)
>
> > + * migration entry unexpectedly being present in the PMD, so explicitly
> > + * check for this and bail out if so.
> > + */
>
> --
> Sincerely yours,
> Mike.
Cheers, Lorenzo