Re: [PATCH v5 19/36] proc: include N_MEMORY_PRIVATE nodes in numa_maps output

[email protected] Tue, 21 Jul 2026 18:30:04 +0000
Newsgroups dev.linux.lists.nvdimm,dev.linux.lists.damon,org.kernel.vger.kvm,org.kernel.vger.linux-cxl
Message-ID <[email protected]>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Using ACTION_AGAIN when pte_offset_map_lock() fails can create an infinite loop.
--

--- Patch [19]: [PATCH v5 19/36] proc: include N_MEMORY_PRIVATE nodes in numa_maps output ---
commit 744e7cd9225bc94011608ebdc2dbdb49cbdf8476
Author: Gregory Price <[email protected]>

proc: include N_MEMORY_PRIVATE nodes in numa_maps output

numa_maps collects per-node page counts in the page-table walkers
and emits them in show_numa_map.  All three filtered by N_MEMORY,
so pages on N_MEMORY_PRIVATE nodes were never gathered/printed.

Accept N_MEMORY_PRIVATE pages in both walkers and emit private nodes
in show_numa_map, so private-node mappings are visible in numa_maps.

> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 817e3e0f91943..e116cd5f157b9 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
[ ... ]
> @@ -3414,7 +3415,8 @@ static struct page *can_gather_numa_stats_pmd(pmd_t pmd,
>  		return NULL;
>  
>  	nid = page_to_nid(page);
> -	if (!node_isset(nid, node_states[N_MEMORY]))
> +	if (!node_isset(nid, node_states[N_MEMORY]) &&
> +	    !node_isset(nid, node_states[N_MEMORY_PRIVATE]))
>  		return NULL;
>  
>  	return page;

[Severity: High]
This is a pre-existing issue, but can the error handling in gather_pte_stats()
lead to an infinite loop?

When reading from procfs memory mapping files (like numa_maps),
pte_offset_map_lock() can fail non-transiently for a PMD migration entry and
return NULL:

fs/proc/task_mmu.c:gather_pte_stats() {
	...
	orig_pte = pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
	if (!pte) {
		walk->action = ACTION_AGAIN;
		return 0;
	}
	...
}

Because this sets walk->action = ACTION_AGAIN, wouldn't the walk_pmd_range()
core unconditionally retry the same PMD entry indefinitely without making
forward progress?

The same pattern also appears to exist in smaps_pte_range(),
clear_refs_pte_range(), pagemap_pmd_range(), and pagemap_scan_pmd_entry().

[ ... ]

-- 
Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=19