From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id EC9C22D29C8; Wed, 7 Oct 2026 00:50:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791334212; cv=none; b=cxgF/r2tJH265G9WIY70GWOyZWiR7KBXpRAQ3r7gVhYuHLODzEFm3QCHvudIz1DreA36eUrQT0iC7ej4OkCAe9Xt7NRwsDXrdOrZWURohfT+bUnziHDDFkR0/Z9ao7Uv3hJfiB0/oFwTzL+RKqCaqsBLrLnlDGQRRZM4NJ18PRc= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791334212; c=relaxed/simple; bh=R7qWdxuWOIY0jw3WKCvunUD5Cwfhw2/36jnKJLylq8E=; h=Date:To:From:Subject:Message-Id; b=IvWWEThlf6b+WlkNBVwgHxc8T+tTaOz9/OmnPkdgAO5Fq9pwv80OEe6OFx9gjRaTteFjBHEYPHle4PCW6inNw1+r1/BctY0yt4V0CsZJ5e9UcDQaDQptJvOXooq7YBN0d9njENaR2XojHWwB/fGcxhMiD0j6lboUYNH84j/C0P8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=nrEEN58x; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="nrEEN58x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id C40D51F0089D; Wed, 7 Oct 2026 00:50:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1791334210; bh=n7AEILXCXpkvgfiLBHTPGeUZgdxX0+/hmE0c4eYB8Ik=; h=Date:To:From:Subject; b=nrEEN58xjXL0BZ1Ue8nCtiioIBK0iFfsn7wR6EyL0wkauqsxx6qu2Uir9iuVt8gqf yCsAqpclIWsTjSjvyYiIndu5aj00MU+K+0oESyuEnjpUT02gS+km9n2Db8AlNroDgL gOvpZFceiBonvP//GdcgduUn/nvten7y2U1uOguw= Date: Tue, 06 Oct 2026 17:50:10 -0700 To: mm-commits@vger.kernel.org,ziy@nvidia.com,ying.huang@linux.alibaba.com,urezki@gmail.com,stable@vger.kernel.org,rakie.kim@sk.com,matthew.brost@intel.com,joshua.hahnjy@gmail.com,david@kernel.org,chenwandun@huawei.com,chelsyratnawat2001@gmail.com,byungchul@sk.com,apopple@nvidia.com,gourry@gourry.net,akpm@linux-foundation.org From: Andrew Morton Subject: [merged mm-stable] mm-mempolicy-take-a-cpuset-cookie-for-the-interleave-node-count.patch removed from -mm tree Message-Id: <20261007005010.C40D51F0089D@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The quilt patch titled Subject: mm/mempolicy: take a cpuset cookie for the interleave node count has been removed from the -mm tree. Its filename was mm-mempolicy-take-a-cpuset-cookie-for-the-interleave-node-count.patch This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm ------------------------------------------------------ From: Gregory Price Subject: mm/mempolicy: take a cpuset cookie for the interleave node count Date: Fri, 28 Aug 2026 15:31:11 -0400 alloc_pages_bulk_interleave() counts pol->nodes without a cpuset cookie: nodes = nodes_weight(pol->nodes); nr_pages_per_node = nr_pages / nodes; nodemask_t spans several words once MAX_NUMNODES exceeds BITS_PER_LONG, so a concurrent cpuset rebind can tear that read and yield an empty mask even though neither version of it was empty. The call then allocates nothing and returns 0. Some compilers will hoist the loop entry test above the division, because nr_pages_per_node is dead when the loop does not run. 682e: call ... <- nodes_weight() 6838: test %eax,%eax 683a: jle 692d <- nodes <= 0 skips the loop 684a: div %rcx So in most deployments, this div/0 is unreachable - but nothing in the source guarantees that, it's just not easily exercised. Take the cookie around the count and bail if the mask really is empty. Only the count needs it, interleave_nodes() takes the cookie itself so so a torn read there is already retried. A rebind landing mid-loop can still leave the count disagreeing with the mask, so the loop may revisit a node or skip one - but a rebind where nodes change causes migration, so a handful of misplaced pages isn't catastrophic in any sense. Measured on a 72 node VM (NODES_SHIFT=10) with a cgroup v2 cpuset flipping cpuset.mems between a word 0 and a word 1 node set, and the two word read artificially widened: 330 zero counts in 130414 calls without the cookie, and 401 retries with it. Link: https://lore.kernel.org/20260828193111.1023497-1-gourry@gourry.net Fixes: c00b6b961099 ("mm/vmalloc: introduce alloc_pages_bulk_array_mempolicy to accelerate memory allocation") Signed-off-by: Gregory Price (Meta) Signed-off-by: Andrew Morton Reported-by: Chelsy Ratnawat Closes: https://lore.kernel.org/all/20250907160829.91628-1-chelsyratnawat2001@gmail.com/ Reviewed-by: Huang Ying Assisted-by: Claude:claude-opus-5 Cc: Alistair Popple Cc: Byungchul Park Cc: Chenwandun Cc: David Hildenbrand Cc: Joshua Hahn Cc: Matthew Brost Cc: Rakie Kim Cc: "Uladzislau Rezki (Sony)" Cc: Zi Yan Cc: --- mm/mempolicy.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) --- a/mm/mempolicy.c~mm-mempolicy-take-a-cpuset-cookie-for-the-interleave-node-count +++ a/mm/mempolicy.c @@ -2592,6 +2592,7 @@ static unsigned long alloc_pages_bulk_in struct mempolicy *pol, unsigned long nr_pages, struct page **page_array) { + unsigned int cpuset_mems_cookie; int nodes; unsigned long nr_pages_per_node; int delta; @@ -2599,7 +2600,16 @@ static unsigned long alloc_pages_bulk_in unsigned long nr_allocated; unsigned long total_allocated = 0; - nodes = nodes_weight(pol->nodes); + /* count the nodes, retry if a rebind happened during the read */ + do { + cpuset_mems_cookie = read_mems_allowed_begin(); + nodes = nodes_weight(pol->nodes); + } while (read_mems_allowed_retry(cpuset_mems_cookie)); + + /* if the nodemask has become invalid, we cannot do anything */ + if (!nodes) + return 0; + nr_pages_per_node = nr_pages / nodes; delta = nr_pages - nodes * nr_pages_per_node; _ Patches currently in -mm which might be from gourry@gourry.net are mm-memory_hotplug-factor-out-node_is_memoryless.patch mm-mempolicy-use-vm_normal_folio_pmd-in-queue_folios_pmd.patch mm-madvise-use-vm_normal_folio_pmd-in-cold-pageout-pmd-range.patch mm-refactor-find_next_best_node-to-find_next_best_node_in.patch mm-page_alloc-refactor-build_node_zonelist-out-of-build_zonelists.patch proc-task_mmu-handle-special-pmds-in-clear_refs-and-pagemap.patch mm-madvise-reclaim-isolated-folios-if-pte-restart-fails.patch mm-madvise-use-folio_trylock-in-the-cold-pageout-pmd-split.patch