Re: [PATCH] mm/migrate: Putback split folios when numa hint migration fails

[Peter Xu]

On Mon, Jul 08, 2024 at 04:04:07PM -0700, Andrew Morton wrote:
> On Mon,  8 Jul 2024 17:55:37 -0400 Peter Xu <peterx@xxxxxxxxxx> wrote:
> 
> > This issue is not from any report yet, but by code observation only.
> > 
> > This is yet another fix besides Hugh's patch [1] but on relevant code path,
> > where eager split of folio can happen if the folio is already on deferred
> > list during a folio migration.
> > 
> > Here the issue is NUMA path (migrate_misplaced_folio()) may start to
> > encounter such folio split now even with MR_NUMA_MISPLACED hint applied.
> > Then when migrate_pages() didn't migrate all the folios, it's possible the
> > split small folios be put onto the list instead of the original folio.
> > Then putting back only the head page won't be enough.
> > 
> > Fix it by putting back all the folios on the list.
> 
> mm/migrate.c: In function 'migrate_misplaced_folio':
> mm/migrate.c:2624:13: error: unused variable 'nr_pages' [-Werror=unused-variable]
>  2624 |         int nr_pages = folio_nr_pages(folio);
>       |             ^~~~~~~~
> 
> Worrisome.  Which kernel version was this tested against?

mm-unstable (and on top of a few of my other totally irrelevant patches),
and I thought it also applied to mm-stable.

Totally missed this warning when still with WERROR=off locally when
building against this patch, my apologies.

> 
> > Don't need to copy stable if this can still hit 6.10..  Only smoke tested.
> 
> Also worrisome.  Are we to take an only-smoke-tested patch which
> doesn't apply to mainline and which doesn't compile on mm-unstable into
> mainline based on "only smoke tested"?

Hmm so it doesn't apply to mainline..  For the smoke test part, I was not
confident to reproduce it, and I just stumbled over it when looking at the
real BUG_ON we hit.  I thought it might be a good idea to send a patch
before everyone forgets about it.

I think it is easily overlooked probably because the issue wasn't
obvious. IIUC the sympton of hitting it should be that we leak a few of
those tail pages even if they're freed in the future from the mappings.  I
am not sure how much an issue with keep being !lru for them besides the
leaked refcounts, perhaps only vmscan won't see them.  After all, all these
is based on the chance of hitting this case and it should be rare.  I don't
think I know well enough to say.

Considering that nobody yelled after rc5 until now, and this is only
something I observed when looking at the more severe issue Hugh fixed..
maybe we should target this for next release, then stablize it and wait for
a backport to 6.10?

Thanks,

-- 
Peter Xu