kernel/mm/page_owner.c, branch 0x221E-v0.0.1-v6.19

mm/page_owner: fix memory leak in page_owner_stack_fops->release()

2025-12-23T19:23:17Z

The page_owner_stack_fops->open() callback invokes seq_open_private(), therefore its corresponding ->release() callback must call seq_release_private(). Otherwise it will cause a memory leak of struct stack_print_ctx. Link: https://lkml.kernel.org/r/20251219074232.136482-1-ranxiaokai627@163.com Fixes: 765973a09803 ("mm,page_owner: display all stacks and their count") Signed-off-by: Ran Xiaokai Acked-by: Michal Hocko Acked-by: Vlastimil Babka Cc: Andrey Konovalov Cc: Brendan Jackman Cc: Johannes Weiner Cc: Marco Elver Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton

mm/page_owner: simplify zone iteration logic in init_early_allocated_pages()

2025-11-17T01:28:01Z

The current implementation uses nested loops: first iterating over all online nodes, then over zones within each node. This can be simplified by using the for_each_populated_zone() macro which directly iterates through all populated zones. This change: 1. Removes the intermediate init_zones_in_node() function 2. Simplifies init_early_allocated_pages() to use direct zone iteration 3. Updates init_pages_in_zone() to take only zone parameter and access node_id via zone->zone_pgdat The functionality remains identical, but the code is cleaner and more maintainable. Link: https://lkml.kernel.org/r/20250930092153.843109-2-husong@kylinos.cn Signed-off-by: Song Hu Reviewed-by: Vlastimil Babka Reviewed-by: Ye Liu Acked-by: Vlastimil Babka Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton

mm/page_owner: rename proc-prefixed variables for clarity

2025-11-17T01:28:01Z

`proc_page_owner_operations` and related variables were renamed to `page_owner_fops` to better reflect their association with `debugfs` rather than `/proc`. This improves code clarity and aligns with kernel naming conventions. Link: https://lkml.kernel.org/r/20250930092153.843109-1-husong@kylinos.cn Signed-off-by: Song Hu Acked-by: Vlastimil Babka Reviewed-by: Ye Liu Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Zi Yan Signed-off-by: Andrew Morton

mm/page_owner: add debugfs file 'show_stacks_handles'

2025-11-17T01:27:59Z

Add the file 'show_stacks_handles' to show just stack traces and their handles, in order to resolve stack traces and handles (i.e., to identify the stack traces for handles in previous reads from 'show_handles'). All stacks/handles must show up, regardless of their number of pages, that might have become zero or no longer make 'count_threshold', but made it in previous reads from 'show_handles' -- and need to be resolved later. P.S.: now, print the extra newline independently of the number of pages. Link: https://lkml.kernel.org/r/20251001175611.575861-5-mfo@igalia.com Signed-off-by: Mauricio Faria de Oliveira Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Oscar Salvador Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton

mm/page_owner: add debugfs file 'show_handles'

2025-11-17T01:27:58Z

Add the flag STACK_PRINT_FLAG_HANDLE to print a stack's handle number from stackdepot, and add the file 'show_handles' to show just handles and their number of pages. This is similar to 'show_stacks', with handles instead of stack traces. Link: https://lkml.kernel.org/r/20251001175611.575861-4-mfo@igalia.com Signed-off-by: Mauricio Faria de Oliveira Reviewed-by: Oscar Salvador Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton

mm/page_owner: add struct stack_print_ctx.flags

2025-11-17T01:27:58Z

Add the flags field to stack_print_ctx, and define two flags for current behavior (printing stack traces and their number of base pages). The plumbing of flags is debugfs_create_file(data) -> inode.i_private -> page_owner_stack_open() -> stack_print_ctx.flags -> stack_print(). No behavior change intended. Link: https://lkml.kernel.org/r/20251001175611.575861-3-mfo@igalia.com Signed-off-by: Mauricio Faria de Oliveira Reviewed-by: Oscar Salvador Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton

mm/page_owner: introduce struct stack_print_ctx

2025-11-17T01:27:58Z

Patch series "mm/page_owner: add debugfs files 'show_handles' and 'show_stacks_handles'", v2. Context: The page_owner debug feature can help understand a particular situation in in a point in time (e.g., identify biggest memory consumers; verify memory counters that do not add up). Another useful usecase is to collect data repeatedly over time, and use it for profiling, monitoring, and even comparing different kernel versions, at the stack trace level (e.g., watch for trends, leaks, correlations, and regressions). For this usecase, userspace periorically collects the data from page_owner and organizes it in data structures appropriate for access per-stack trace. Problem: The usecase of tracking memory usage per stack trace (or tracking it for a particular stack trace) requires uniquely identifying each stack trace (i.e., keys to store their memory usage over periodic data collections). This has to be done for every stack trace in every sample/data collection, even if tracking only one stack trace (to identify it among all others). Therefore, an approach like hashing the stack traces in userspace to create unique keys/identifiers for them during post-processing can quickly become expensive, considering the repetition and a growing number of stack traces. Solution: Fortunately, the kernel can provide a unique identifier for stack traces in page_owner, which is the handle number in stackdepot. This eliminates the need for creating keys (hashing) in userspace during post-processing. Additionally, with that information, the stack traces themselves are not needed until the memory usage should be resolved from a handle to a stack trace (say, to look at the stack traces of a few top consumers). This can reduce the amount of text emitted/copied by the kernel to userspace, and save userspace from matching and discarding stack traces when not needed. Changes: This patchset adds 2 files to provide information, like 'show_stacks': - show_handles: print handle number and number of pages (no stack traces) - show_stacks_handles: print handle numbers and stack traces (no pages) Now, it's possible to periodically collect data with handle numbers (keys) and without stack traces (lower overhead) from 'show_handles', and later do a final collection with handles and stack traces from 'show_stacks_handles' to resolve the handles to their stack traces. The output format follows the existing 'show_stacks' file, for simplicity, but it can certainly be changed if a different format is more convenient. Example: The number of base pages collected can be stored per-handle number over the periodic data collections, and finally resolved to stack traces per-handle number as well with a final collection. Later, one can, for example, identify the biggest consumers and watch their trends or correlate increases/decreases with other events in the system, or watch a particular stack trace(s) of interest during development. Testing: Tested on next-20250929. - show_stacks: register_dummy_stack+0x32/0x70 init_page_owner+0x29/0x2f0 page_ext_init+0x27c/0x2b0 mm_core_init+0xdc/0x110 nr_base_pages: 47 - show_handles: handle: 1 nr_base_pages: 47 - show_stacks_handles: register_dummy_stack+0x32/0x70 init_page_owner+0x29/0x2f0 page_ext_init+0x27c/0x2b0 mm_core_init+0xdc/0x110 handle: 1 - count_threshold: # echo 100 >/sys/kernel/debug/page_owner_stacks/count_threshold # grep register_dummy_stack show_stacks # not present # grep -B4 '^handle: 1$' show_handles # not present # grep -B4 '^handle: 1$' show_stacks_handles # present register_dummy_stack+0x32/0x70 init_page_owner+0x29/0x2f0 page_ext_init+0x27c/0x2b0 mm_core_init+0xdc/0x110 handle: 1 This patch (of 5): Currently, struct seq_file.private is used as an iterator in stack_list by stack_start|next(), for stack_print(). Create a context struct for this, in order to add another field next. No behavior change intended. P.S.: page_owner_stack_open() is expanded with separate statements for variable definition and return just in preparation for the next patch. Link: https://lkml.kernel.org/r/20251001175611.575861-1-mfo@igalia.com Link: https://lkml.kernel.org/r/20251001175611.575861-2-mfo@igalia.com Signed-off-by: Mauricio Faria de Oliveira Reviewed-by: Oscar Salvador Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Oscar Salvador Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton

mm: don't spin in add_stack_record when gfp flags don't allow

2025-10-15T20:24:33Z

syzbot was able to find the following path: add_stack_record_to_list mm/page_owner.c:182 [inline] inc_stack_record_count mm/page_owner.c:214 [inline] __set_page_owner+0x2c3/0x4a0 mm/page_owner.c:333 set_page_owner include/linux/page_owner.h:32 [inline] post_alloc_hook+0x240/0x2a0 mm/page_alloc.c:1851 prep_new_page mm/page_alloc.c:1859 [inline] get_page_from_freelist+0x21e4/0x22c0 mm/page_alloc.c:3858 alloc_pages_nolock_noprof+0x94/0x120 mm/page_alloc.c:7554 Don't spin in add_stack_record_to_list() when it is called from *_nolock() context. Link: https://lkml.kernel.org/r/CAADnVQK_8bNYEA7TJYgwTYR57=TTFagsvRxp62pFzS_z129eTg@mail.gmail.com Fixes: 97769a53f117 ("mm, bpf: Introduce try_alloc_pages() for opportunistic page allocation") Signed-off-by: Alexei Starovoitov Reported-by: syzbot+8259e1d0e3ae8ed0c490@syzkaller.appspotmail.com Reported-by: syzbot+665739f456b28f32b23d@syzkaller.appspotmail.com Acked-by: Vlastimil Babka Reviewed-by: Oscar Salvador Cc: Brendan Jackman Cc: Johannes Weiner Cc: Michal Hocko Cc: Suren Baghdasaryan Cc: Zi Yan Cc: Signed-off-by: Andrew Morton

mm/page_owner: convert set_page_owner_migrate_reason() to folios

2025-07-20T01:59:57Z

Both callers of set_page_owner_migrate_reason() use folios. Convert the function to take a folio directly and move the &folio->page conversion inside __set_page_owner_migrate_reason(). Link: https://lkml.kernel.org/r/20250711145910.90135-1-sidhartha.kumar@oracle.com Signed-off-by: Sidhartha Kumar Reviewed-by: Matthew Wilcox (Oracle) Acked-by: David Hildenbrand Reviewed-by: Zi Yan Reviewed-by: Vishal Moola (Oracle) Reviewed-by: Oscar Salvador Cc: Muchun Song Cc: Vlastimil Babka Signed-off-by: Andrew Morton

mm: rename try_alloc_pages() to alloc_pages_nolock()

2025-05-22T21:55:37Z

The "try_" prefix is confusing, since it made people believe that try_alloc_pages() is analogous to spin_trylock() and NULL return means EAGAIN. This is not the case. If it returns NULL there is no reason to call it again. It will most likely return NULL again. Hence rename it to alloc_pages_nolock() to make it symmetrical to free_pages_nolock() and document that NULL means ENOMEM. Link: https://lkml.kernel.org/r/20250517003446.60260-1-alexei.starovoitov@gmail.com Signed-off-by: Alexei Starovoitov Acked-by: Vlastimil Babka Acked-by: Johannes Weiner Reviewed-by: Shakeel Butt Acked-by: Harry Yoo Cc: Andrii Nakryiko Cc: Kumar Kartikeya Dwivedi Cc: Michal Hocko Cc: Peter Zijlstra Cc: Sebastian Andrzej Siewior Cc: Steven Rostedt Signed-off-by: Andrew Morton