On Thu, 22 Jul 2021 09:27:50 +0200 David Hildenbrand <david@xxxxxxxxxx> wrote:
> On 22.07.21 07:48, Nicholas Piggin wrote:
> > Similarly to commit 2da9f6305f306 ("mm/vmscan: fix NR_ISOLATED_FILE
> > corruption on 64-bit"), fix -ve int -> unsigned int -> long bug.
> >
> > Reported-by: Alexey Kardashevskiy <aik@xxxxxxxxx>
> > Fixes: c5fc5c3ae0c84 ("mm: migrate: account THP NUMA migration counters correctly")
> > Signed-off-by: Nicholas Piggin <npiggin@xxxxxxxxx>
> > ---
> > mm/migrate.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/mm/migrate.c b/mm/migrate.c
> > index 34a9ad3e0a4f..7e240437e7d9 100644
> > --- a/mm/migrate.c
> > +++ b/mm/migrate.c
> > @@ -2068,7 +2068,7 @@ int migrate_misplaced_page(struct page *page, struct vm_area_struct *vma,
> > LIST_HEAD(migratepages);
> > new_page_t *new;
> > bool compound;
> > - unsigned int nr_pages = thp_nr_pages(page);
> > + int nr_pages = thp_nr_pages(page);
> >
> > /*
> > * PTE mapped THP or HugeTLB page can't reach here so the page could
> >
>
> This is too fragile to silently break again IMHO. Should we similarly to
> 2da9f6305f306 handle the conversion explicitly inside the
> mod_node_page_state() call?
And please don't send us off to loo at another commit to understand
this one. A full standalone changelog, please.
Preferably with a description of user-visible effects. 2da9f6305f306
said "Symptoms include CMA allocations hanging forever holding the
cma_mutex due to alloc_contig_range->...->isolate_migratepages_block
waiting forever in "while (unlikely(too_many_isolated(pgdat)))". Is
that also the case with this bug?
