mm/page_owner: add filter infrastructure for print_mode and NUMA filtering

Add a print_mode filter to page_owner that allows users to choose between printing full stack traces or only stack handles, significantly reducing output size for debugging and analysis.

The filter provides a string-based interface under /sys/kernel/debug/page_owner_filter/:
- Reading shows the current mode with [] brackets around active option
- Writing accepts "full_stack" or "stack_handle" strings

The default full_stack mode maintains backward compatibility with existing usage, displaying complete stack traces for each page allocation.

The stack_handle mode dramatically reduces log size by showing only the handle number instead of the full stack trace. The mapping from handles to actual stack traces can be obtained via the show_stacks_handles interface.

Example usage:

  # echo stack_handle > /sys/kernel/debug/page_owner_filter/print_mode
  # cat /sys/kernel/debug/page_owner_filter/print_mode
  full_stack [stack_handle]
  # cat /sys/kernel/debug/page_owner
  Page allocated via order 0, migratetype Unmovable, gfp_mask 0x1100ca,
  pid 1, tgid 1 (systemd), ts 123456789 ns
  PFN 0x1000 type Unmovable Block 1 type Unmovable
  Flags 0x3fffe800000084(referenced|lru|active|private|node=0|zone=1)
  handle: 17432583
  ...

Reviewed-by SeongJae Park <[email protected]>

Signed-off-by Zhen Ni <[email protected]>

---

Quoted 29 lines · Zhen Ni

Add a print_mode filter to page_owner that allows users to choose between printing full stack traces or only stack handles, significantly reducing output size for debugging and analysis.

The filter provides a string-based interface under /sys/kernel/debug/page_owner_filter/:
- Reading shows the current mode with [] brackets around active option
- Writing accepts "full_stack" or "stack_handle" strings

The default full_stack mode maintains backward compatibility with existing usage, displaying complete stack traces for each page allocation.

The stack_handle mode dramatically reduces log size by showing only the handle number instead of the full stack trace. The mapping from handles to actual stack traces can be obtained via the show_stacks_handles interface.

Example usage:

   # echo stack_handle > /sys/kernel/debug/page_owner_filter/print_mode
   # cat /sys/kernel/debug/page_owner_filter/print_mode
   full_stack [stack_handle]
   # cat /sys/kernel/debug/page_owner
   Page allocated via order 0, migratetype Unmovable, gfp_mask 0x1100ca,
   pid 1, tgid 1 (systemd), ts 123456789 ns
   PFN 0x1000 type Unmovable Block 1 type Unmovable
   Flags 0x3fffe800000084(referenced|lru|active|private|node=0|zone=1)
   handle: 17432583
   ...

Quoted 2 lines

Reviewed-by SeongJae Park <[email protected]>

Signed-off-by Zhen Ni <[email protected]>

Overall looks good to me, one comment below

Reviewed-by Oscar Salvador <[email protected]>

Quoted 1 line

---

...

Quoted 4 lines

---
  mm/page_owner.c | 82 +++++++++++++++++++++++++++++++++++++++++++++++--
  1 file changed, 80 insertions(+), 2 deletions(-)

mm/page_owner.c line 3

Quoted 8 lines

mm/page_owner.c +1 -0

index 8178e0be557f..27a412c52d41 100644
@@ -1,5 +1,6 @@
  // SPDX-License-Identifier: GPL-2.0
  #include <linux/debugfs.h>
+#include <linux/fs.h>

Why do we need this?

Add NUMA node filtering functionality to page_owner to allow filtering pages by specific NUMA node(s). This is useful for NUMA-aware memory allocation analysis and debugging.

The filter supports flexible nodelist input formats:
- Single node: echo "0" > nid
- Multiple nodes: echo "0,2,3" > nid
- Node range: echo "0-3" > nid
- Mixed format: echo "0,2-4,7" > nid
- Clear filter: echo > nid (empty string)

The implementation uses nodemask_t for efficient multi-node filtering and nodelist_parse() for flexible input parsing. Empty input clears the filter.

Note: Access to nid_mask uses plain load/store without locking because nodemask_t is too large (128 bytes) for READ_ONCE/WRITE_ONCE. This is safe for debug use: low-frequency changes and torn reads would only cause temporary inconsistency in debug output.

Signed-off-by Zhen Ni <[email protected]>

---

---
 mm/page_owner.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 92 insertions(+)

mm/page_owner.c +0 -0

index 27a412c52d41..8a38005539ff 100644

mm/page_owner.c +3 -0

@@ -700,6 +708,9 @@ read_page_owner(struct file *file, char __user *buf, size_t count, loff_t *ppos)
 	while (!pfn_valid(pfn) && (pfn & (MAX_ORDER_NR_PAGES - 1)) != 0)
 		pfn++;
 
+	mask = owner_filter.nid_mask;
+	filter_by_nid = !nodes_empty(mask);
+
 	/* Find an allocated page */
 	for (; pfn < max_pfn; pfn++) {
 		/*

mm/page_owner.c +26 -0

+			int nid = page_to_nid(page);
+
+			if (!node_isset(nid, mask))
+				goto ext_put_continue;
+		}
+
 		/*
 		 * Some pages could be missed by concurrent allocation or free,
 		 * because we don't hold the zone lock.

@@ -1043,6 +1062,77 @@ static const struct file_operations page_owner_print_mode_fops = {
 	.llseek = default_llseek,
 };
 
+static ssize_t nid_filter_write(struct file *file,
+				 const char __user *buf,
+				 size_t count, loff_t *ppos)
+{
+	char *kbuf;
+	nodemask_t mask;
+	int ret;
+
+	/*
+	 * Limit input size to handle worst-case nodelist (all nodes).
+	 * Worst case per node: ",NNNNN" (comma + 5-digit node number) = 6 bytes.
+	 */
+	if (count > (6 * MAX_NUMNODES))
+		return -EINVAL;
+
+	kbuf = kmalloc_objs(*kbuf, count + 1);
+	if (!kbuf)
+		return -ENOMEM;
+
+	if (strncpy_from_user(kbuf, buf, count) < 0) {

mm/page_owner.c +7 -0

+
+	owner_filter.nid_mask = mask;
+	ret = count;
+
+out_free:
+	kfree(kbuf);
+	return ret;

Quoted 22 lines · Zhen Ni

Add NUMA node filtering functionality to page_owner to allow filtering pages by specific NUMA node(s). This is useful for NUMA-aware memory allocation analysis and debugging.

The filter supports flexible nodelist input formats:
- Single node: echo "0" > nid
- Multiple nodes: echo "0,2,3" > nid
- Node range: echo "0-3" > nid
- Mixed format: echo "0,2-4,7" > nid
- Clear filter: echo > nid (empty string)

The implementation uses nodemask_t for efficient multi-node filtering and nodelist_parse() for flexible input parsing. Empty input clears the filter.

Note: Access to nid_mask uses plain load/store without locking because nodemask_t is too large (128 bytes) for READ_ONCE/WRITE_ONCE. This is safe for debug use: low-frequency changes and torn reads would only cause temporary inconsistency in debug output.

Signed-off-by Zhen Ni <[email protected]>

---

...

Quoted 8 lines

---
  mm/page_owner.c | 92 +++++++++++++++++++++++++++++++++++++++++++++++++
  1 file changed, 92 insertions(+)

mm/page_owner.c +0 -0

index 27a412c52d41..8a38005539ff 100644

...

Quoted 14 lines

mm/page_owner.c +3 -0

@@ -700,6 +708,9 @@ read_page_owner(struct file *file, char __user *buf, size_t count, loff_t *ppos)
  	while (!pfn_valid(pfn) && (pfn & (MAX_ORDER_NR_PAGES - 1)) != 0)
  		pfn++;
 
+	mask = owner_filter.nid_mask;
+	filter_by_nid = !nodes_empty(mask);
+
  	/* Find an allocated page */
  	for (; pfn < max_pfn; pfn++) {
  		/*

@@ -732,6 +743,14 @@ read_page_owner(struct file *file, char __user *buf, size_t count, loff_t *ppos)
  		if (unlikely(!page_ext))
  			continue;
 

mm/page_owner.c read_page_owner(struct file *file, char __user *buf, size_t count, loff_t *ppos) · line 747

Quoted 2 lines

mm/page_owner.c +2 -0

+		/* NUMA node filter using bitmask */
+		if (filter_by_nid) {

This comment is kinda pointless because it explains something that the code makes it quite clear.
Either drop it, or just go with "NUMA node filter", but "using bitmask" does not really add much.

Quoted 34 lines

mm/page_owner.c +26 -0

+			int nid = page_to_nid(page);
+
+			if (!node_isset(nid, mask))
+				goto ext_put_continue;
+		}
+
  		/*
  		 * Some pages could be missed by concurrent allocation or free,
  		 * because we don't hold the zone lock.

@@ -1043,6 +1062,77 @@ static const struct file_operations page_owner_print_mode_fops = {
  	.llseek = default_llseek,
  };
 
+static ssize_t nid_filter_write(struct file *file,
+				 const char __user *buf,
+				 size_t count, loff_t *ppos)
+{
+	char *kbuf;
+	nodemask_t mask;
+	int ret;
+
+	/*
+	 * Limit input size to handle worst-case nodelist (all nodes).
+	 * Worst case per node: ",NNNNN" (comma + 5-digit node number) = 6 bytes.
+	 */
+	if (count > (6 * MAX_NUMNODES))
+		return -EINVAL;
+
+	kbuf = kmalloc_objs(*kbuf, count + 1);
+	if (!kbuf)
+		return -ENOMEM;
+
+	if (strncpy_from_user(kbuf, buf, count) < 0) {

mm/page_owner.c static const struct file_operations page_owner_print_mode_fops = { · line 1094

Quoted 10 lines

mm/page_owner.c +10 -0

+		ret = -EFAULT;
+		goto out_free;
+	}
+	kbuf[count] = '\0';
+
+	/* Support nodelist format like "0", "0,2", "0-3", or empty to clear */
+	if (nodelist_parse(kbuf, mask)) {
+		ret = -EINVAL;
+		goto out_free;
+	}

nodelist_parse() can also return other return values besides EINVAL. Something like

ret = nodelist_parse(...)
if (ret < 0)
return ret

might be cleaner.

mm/page_owner.c static const struct file_operations page_owner_print_mode_fops = { · line 1100

Quoted 6 lines

mm/page_owner.c +6 -0

+
+	/* Validate that all specified nodes actually exist in the system */
+	if (!nodes_subset(mask, node_states[N_MEMORY])) {
+		ret = -EINVAL;
+		goto out_free;
+	}

Ok, I get that since you want to filter allocations by numa nodes, you want to make sure that those nodes have memory.
Although that might change due to concurrent memory-hotplug operations, but that is a different story.

I do not like the comment though, because we can have other nodes existing in the system with no memory (e.g: memoryless nodes only having cpus, or none of them), so I would make that clearer:

"
/*
* We want to filter memory allocations by numa nodes, so make sure
* that the specified nodes have memory.
*/
"

or something along those lines.

Quoted 12 lines

mm/page_owner.c +12 -0

+
+	owner_filter.nid_mask = mask;
+	ret = count;
+
+out_free:
+	kfree(kbuf);
+	return ret;
+}
+
+static int nid_filter_show(struct seq_file *m, void *v)
+{
+	nodemask_t mask = owner_filter.nid_mask;

mm/page_owner.c static const struct file_operations page_owner_print_mode_fops = { · line 1117

Quoted 5 lines

mm/page_owner.c +5 -0

+
+	if (nodes_empty(mask))
+		seq_puts(m, "\n");
+	else
+		seq_printf(m, "%*pbl\n", nodemask_pr_args(&mask));

is not nodemask_pr_args clever enough to not print anything or print "0" if the nmask is NODE_MASK_NONE?

Add documentation for the page_owner filter functionality, including:
- Print mode filter (full stack vs stack handle)
- NUMA node filter (single node, multiple nodes, ranges)
- Usage examples for both filters

Reviewed-by SeongJae Park <[email protected]>

Signed-off-by Zhen Ni <[email protected]>

Solution
========

This patch series introduces a flexible filter infrastructure with two initial filters:

1. **Print Mode Filter**: Outputs only stack handles instead of full stack traces. The handle-to-stack mapping can be retrieved from the existing show_stacks_handles interface. This dramatically reduces output size while preserving all allocation metadata.

2. **NUMA Node Filter**: Allows filtering pages by specific NUMA node(s) using flexible nodelist format, enabling targeted analysis of memory issues in NUMA-aware deployments.

Quoted 11 lines · Zhen Ni

Solution
========

This patch series introduces a flexible filter infrastructure with two initial filters:

1. **Print Mode Filter**: Outputs only stack handles instead of full stack traces. The handle-to-stack mapping can be retrieved from the existing show_stacks_handles interface. This dramatically reduces output size while preserving all allocation metadata.

Quoted 3 lines

2. **NUMA Node Filter**: Allows filtering pages by specific NUMA node(s) using flexible nodelist format, enabling targeted analysis of memory issues in NUMA-aware deployments.

How does this work when there are multiple consumers of the interface? E.g per numa tool to watch node lock page_owner information?

Quoted 12 lines · Michal Hocko

Quoted 11 lines · Zhen Ni

Solution
========

This patch series introduces a flexible filter infrastructure with two initial filters:

1. **Print Mode Filter**: Outputs only stack handles instead of full stack traces. The handle-to-stack mapping can be retrieved from the existing show_stacks_handles interface. This dramatically reduces output size while preserving all allocation metadata.

Quoted 7 lines

Quoted 3 lines

2. **NUMA Node Filter**: Allows filtering pages by specific NUMA node(s) using flexible nodelist format, enabling targeted analysis of memory issues in NUMA-aware deployments.

How does this work when there are multiple consumers of the interface? E.g per numa tool to watch node lock page_owner information?

I understand your concern about concurrent access. Are you asking about this scenario?

Scenario: Multiple tools monitoring different NUMA nodes
Tool 1: echo "0" > nid && cat page_owner > node0.log Tool 2: echo "1" > nid && cat page_owner > node1.log

The current global filter implementation would have race conditions in this case.

Quoted 29 lines · zhen.ni

Quoted 12 lines · Michal Hocko

Quoted 11 lines · Zhen Ni

Solution
========

This patch series introduces a flexible filter infrastructure with two initial filters:

1. **Print Mode Filter**: Outputs only stack handles instead of full stack traces. The handle-to-stack mapping can be retrieved from the existing show_stacks_handles interface. This dramatically reduces output size while preserving all allocation metadata.

Quoted 7 lines

Quoted 3 lines

2. **NUMA Node Filter**: Allows filtering pages by specific NUMA node(s) using flexible nodelist format, enabling targeted analysis of memory issues in NUMA-aware deployments.

How does this work when there are multiple consumers of the interface? E.g per numa tool to watch node lock page_owner information?

I understand your concern about concurrent access. Are you asking about this scenario?

Scenario: Multiple tools monitoring different NUMA nodes
Tool 1: echo "0" > nid && cat page_owner > node0.log Tool 2: echo "1" > nid && cat page_owner > node1.log

Quoted 2 lines

The current global filter implementation would have race conditions in this case.

That makes the interface rather broken in my eyes TBH. Is there any way to make the filter local to the fd?

Quoted 30 lines · Michal Hocko

Quoted 29 lines · zhen.ni

Quoted 12 lines · Michal Hocko

Quoted 11 lines · Zhen Ni

Solution
========

This patch series introduces a flexible filter infrastructure with two initial filters:

1. **Print Mode Filter**: Outputs only stack handles instead of full stack traces. The handle-to-stack mapping can be retrieved from the existing show_stacks_handles interface. This dramatically reduces output size while preserving all allocation metadata.

Quoted 7 lines

Quoted 3 lines

2. **NUMA Node Filter**: Allows filtering pages by specific NUMA node(s) using flexible nodelist format, enabling targeted analysis of memory issues in NUMA-aware deployments.

How does this work when there are multiple consumers of the interface? E.g per numa tool to watch node lock page_owner information?

I understand your concern about concurrent access. Are you asking about this scenario?

Scenario: Multiple tools monitoring different NUMA nodes
Tool 1: echo "0" > nid && cat page_owner > node0.log Tool 2: echo "1" > nid && cat page_owner > node1.log

Quoted 5 lines

Quoted 2 lines

The current global filter implementation would have race conditions in this case.

That makes the interface rather broken in my eyes TBH. Is there any way to make the filter local to the fd?

I agree that the global filter state creates race conditions for concurrent consumers.

Regarding per-fd filters, I've looked into this approach. The main challenge is that per-fd filter state would require changing the current simple usage model:

Current usage:
echo "0" > /sys/kernel/debug/page_owner_filter/nid cat /sys/kernel/debug/page_owner

Per-fd implementation would require:
- Add ioctl interface and allocate filter state in file->private_data
- Change page_owner_fops to add .open/.unlocked_ioctl callbacks
- Provide user-space tool (e.g., ./page_owner_tool --node 0)
- New UAPI header with ioctl definitions

This would replace the current "echo + cat" interface with a tool-based approach.

Alternative: Simple mutex protection to serialize concurrent filter modifications. Though this doesn't fully address concurrent reads, it could mitigate the most obvious race conditions.

I'm wondering if you have any thoughts on the trade-off here. Since page_owner is mainly used for debugging (typically not in concurrent scenarios), would a simpler approach like mutex protection or documenting this limitation be sufficient?

Quoted 50 lines · zhen.ni

Quoted 30 lines · Michal Hocko

Quoted 29 lines · zhen.ni

Quoted 12 lines · Michal Hocko

Quoted 11 lines · Zhen Ni

Solution
========

This patch series introduces a flexible filter infrastructure with two initial filters:

1. **Print Mode Filter**: Outputs only stack handles instead of full stack traces. The handle-to-stack mapping can be retrieved from the existing show_stacks_handles interface. This dramatically reduces output size while preserving all allocation metadata.

Quoted 7 lines

Quoted 3 lines

2. **NUMA Node Filter**: Allows filtering pages by specific NUMA node(s) using flexible nodelist format, enabling targeted analysis of memory issues in NUMA-aware deployments.

How does this work when there are multiple consumers of the interface? E.g per numa tool to watch node lock page_owner information?

I understand your concern about concurrent access. Are you asking about this scenario?

Scenario: Multiple tools monitoring different NUMA nodes

    Tool 1: echo "0" > nid && cat page_owner > node0.log
    Tool 2: echo "1" > nid && cat page_owner > node1.log

Quoted 5 lines

Quoted 2 lines

The current global filter implementation would have race conditions in this case.

That makes the interface rather broken in my eyes TBH. Is there any way to make the filter local to the fd?

I agree that the global filter state creates race conditions for concurrent consumers.

Regarding per-fd filters, I've looked into this approach. The main challenge is that per-fd filter state would require changing the current simple usage model:

Current usage:
echo "0" > /sys/kernel/debug/page_owner_filter/nid cat /sys/kernel/debug/page_owner

Quoted 5 lines

Per-fd implementation would require:
- Add ioctl interface and allocate filter state in file->private_data
- Change page_owner_fops to add .open/.unlocked_ioctl callbacks
- Provide user-space tool (e.g., ./page_owner_tool --node 0)
- New UAPI header with ioctl definitions

ioctl is one option. Have you considered to write the filter state to the page_owner fd to create a local state?

Quoted 2 lines

This would replace the current "echo + cat" interface with a tool-based approach.

Which doesn't sound all that terrible comparing to a non-deterministic behavior of this proposal

Quoted 8 lines

Alternative: Simple mutex protection to serialize concurrent filter modifications. Though this doesn't fully address concurrent reads, it could mitigate the most obvious race conditions.

I'm wondering if you have any thoughts on the trade-off here. Since page_owner is mainly used for debugging (typically not in concurrent scenarios), would a simpler approach like mutex protection or documenting this limitation be sufficient?

The thing is that unless you own the whole machine you never know who might consider information from page_owner interesting to filter and read. So you might easily get garbage. Not completely terrible considering this is debugging interface but I believe we can do better than that.

## Implementation Plan

1. Add per-fd filtering to page_owner file
- Add .open/.release/.write callbacks
- Each file descriptor has its own filter state
- Write filter commands: "nid=0", "mode=stack_handle"

2. Provide user-space tool
- Simple CLI: ./page_owner_tool --nid=0
- Handle fd management internally

## User Experience

Direct access (default: no filter):
cat /sys/kernel/debug/page_owner

With filtering:
./page_owner_tool --nid=0
./page_owner_tool --nid=0,2-3
./page_owner_tool --nid=0 --mode=stack_handle

## Benefits

- Completely eliminates race condition
- Per-fd isolation for concurrent access
- Correct design for multi-consumer scenarios

Does this approach look good to you?

Please let me know if you have any suggestions or concerns.