Re: [PATCH 6.12.y 1/1] mm/rmap: fix soft-dirty and uffd-wp bit loss when remapping zero-filled mTHP subpage to shared zeropage

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

On Fri, Oct 17, 2025 at 07:14:32PM +0800, Lance Yang wrote:
>
>
> On 2025/10/17 18:25, Lance Yang wrote:
> >
> >
> > On 2025/10/17 17:52, Lorenzo Stoakes wrote:
> > > On Fri, Oct 17, 2025 at 04:51:06PM +0800, Lance Yang wrote:
> > > > From: Lance Yang <lance.yang@linux.dev>
> > > >
> > > > When splitting an mTHP and replacing a zero-filled subpage with
> > > > the shared
> > > > zeropage, try_to_map_unused_to_zeropage() currently drops several
> > > > important PTE bits.
> > > >
> > > > For userspace tools like CRIU, which rely on the soft-dirty
> > > > mechanism for
> > > > incremental snapshots, losing the soft-dirty bit means modified
> > > > pages are
> > > > missed, leading to inconsistent memory state after restore.
> > > >
> > > > As pointed out by David, the more critical uffd-wp bit is also dropped.
> > > > This breaks the userfaultfd write-protection mechanism, causing
> > > > writes to
> > > > be silently missed by monitoring applications, which can lead to data
> > > > corruption.
> > > >
> > > > Preserve both the soft-dirty and uffd-wp bits from the old PTE when
> > > > creating the new zeropage mapping to ensure they are correctly tracked.
> > > >
> > > > Link: https://lkml.kernel.org/r/20250930081040.80926-1-
> > > > lance.yang@linux.dev
> > > > Fixes: b1f202060afe ("mm: remap unused subpages to shared
> > > > zeropage when splitting isolated thp")
> > > > Signed-off-by: Lance Yang <lance.yang@linux.dev>
> > > > Suggested-by: David Hildenbrand <david@redhat.com>
> > > > Suggested-by: Dev Jain <dev.jain@arm.com>
> > > > Acked-by: David Hildenbrand <david@redhat.com>
> > > > Reviewed-by: Dev Jain <dev.jain@arm.com>
> > > > Acked-by: Zi Yan <ziy@nvidia.com>
> > > > Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
> > > > Reviewed-by: Harry Yoo <harry.yoo@oracle.com>
> > >
> > > You're missing my R-b...
> >
> > Sorry, I missed it! I just cherry-picked the commit from
> > upstream and didn't notice ...
> >
> > Hopefully Greg can add your Reviewed-by when applying.
>
> Looking at the timeline again, the fix was actually merged
> upstream before your review arrived, so the commit I
> cherry-picked never had your tag to begin with :(
>
> Still hoping Greg can add it!
>

No, I don't want that in that case it'd be odd unless I had separately reviewed
the backport.

I was just unaware this had been taken during the merge window.