Re: [PATCH mm-hotfixes] mm/huge_memory: fix memory corruption on huge zero page move

From: Lorenzo Stoakes (Oracle)

Date: Wed Mar 04 2026 - 06:46:48 EST


On Tue, Mar 03, 2026 at 05:42:26PM -0800, Andrew Morton wrote:
> On Tue, 3 Mar 2026 07:25:32 +0000 Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote:
>
> > On Mon, Mar 02, 2026 at 12:50:32PM -0800, Andrew Morton wrote:
> > > On Mon, 2 Mar 2026 17:19:15 +0000 Lorenzo Stoakes <lorenzo.stoakes@xxxxxxxxxx> wrote:
> > >
> > > > On Mon, Mar 02, 2026 at 06:10:06PM +0100, David Hildenbrand (Arm) wrote:
> > > > > There are already patches in flight:
> > > > >
> > > > > https://lore.kernel.org/r/aaBVaHs8rIkNcwM0@xxxxxxxxxxxxxx
> > > >
> > > > Yup, if people would actually cc the right people I'd not have wasted my
> > > > afternoon.
> > > >
> > > > Replying there.
> > > >
> > >
> > > I'm not sure where this is headed but I'll queue this patch for now, to
> > > get it some testing, to lessen duplicated bug reports and to generally track things.
> >
> > Hi Andrew -
>
> Who is a confused person!
>
> > We should drop my patch and take Chris's.
>
> "my patch" being "mm/huge_memory: fix memory corruption on huge zero
> page move", I assume.

Yes :)

>
> > However, life isn't so simple :) as there's been some confusion with his series
> > since his email client seemed to mess up somehow and a couple patches need to be
> > squashed on one another.
> >
> > So to make life easier, I enclose a squashed patch (combining the commit
> > message from both), with my R-b, T-b tags attached, please replace my patch
> > with this one.
>
> OK. I added your signed-off-by also.

Thanks, probaby appropriate.

>
> > Also, could you make this into a 2 patch series with
> > https://lore.kernel.org/linux-mm/aaBWG4fajXXbjpVN@xxxxxxxxxxxxxx/ _after_ this
> > one?
>
> Well, "mm/huge_memory: Fix use of NULL folio in move_pages_huge_pmd()"
> is a cc:stable mm-hotfix and I don't think "selftests/mm: Add UFFDIO_MOVE
> huge zeropage PMD regression test" is to be treated that way?
>
> If correct, I'd keep "selftests/mm: Add UFFDIO_MOVE huge zeropage PMD
> regression test" as a standalone singleton in mmm-unstable.

If you can _ensure_ the fix appears in the commit list and in -next _before_ the
test then yes.

>
> > mm-unstable (I'm not sure why we're rushing changes there so quick...) had
> > _only_ this regression test patch in it, so we were left with a kernel that
> > splatted on running mm selftests, which is not what we want.
>
> But the regression fix "mm/huge_memory: fix memory corruption on huge
> zero page move" was in mm-hotfixes, cc:stable?

Chris sent 3 patches, the first two addressed the bug, the 3rd was the test. The
first 2 had review feedback, but for some reason the test was taken, and then
taken to mm-unstable almost immediately.

(This is partly why I wasted my time tracking down the bug in mm-unstable and
ended up independently fixing it...)

I think things were confused by Chris's email client somehow messing up sending
the series which we not threaded etc.

>
> > (It seems to me this is what mm-new is for, and it seems we have some holes in
> > our testing still since this got thorugh).
> >
> > Please drop the patch you have for this already in mm-unstable and make sure we
> > only have it _after_ the fix is applied :)
>
> I think you mean to drop "mm/huge_memory: fix memory corruption on huge
> zero page move" from mm-hotfixes.

Yes drop mine.

>
>
> So we now have
>
> "mm/huge_memory: fix use of NULL folio in move_pages_huge_pmd()" in
> mm-hotfixes, cc:stable
>
> "selftests/mm: add UFFDIO_MOVE huge zeropage PMD regression test" in
> mm-unstable, not cc:stable.
>
> btw, "selftests/mm: add UFFDIO_MOVE huge zeropage PMD regression test"
> still has a bunch of unaddressed review comments from David.

I mean let's not have it in mm-unstable then? Things should only transition from
mm-new to mm-unstable/-next if the review is in a good state.

Generally we go easier on tests sure, but if there's any hint of it being a
regression test we have to tread carefully, or we end up splatting people's
kernels and cause unnecessary issues.

>
>

Thanks, Lorenzo