On Thu, 22 Jul 2021 09:27:50 +0200 David Hildenbrand [off-list ref] wrote:

On 22.07.21 07:48, Nicholas Piggin wrote:

quoted

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 <redacted>
Fixes: c5fc5c3ae0c84 ("mm: migrate: account THP NUMA migration counters correctly")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
  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?