kernel/git/stable/linux.git/mm/page_reporting.c, branch master

mm/page_reporting: add page_reporting_delay_ms module parameter

2026-08-25T01:42:58+00:00

Free page reporting currently hardcodes a 2-second interval between reports. This rigid delay cannot accommodate diverse guest workloads. This patch introduces a module parameter, page_reporting_delay_ms (default: 2000), allowing users to tune the reporting rate: - Lower values enable aggressive memory reclamation by returning unused pages to the host immediately. - Higher values help batch pages during spiky allocation/free churn, reducing hypercalls and nested page fault overheads. Setting the delay to 0 is safe and execution is strictly gated by: - reporting is only triggered by high-order page frees. - expensive hypercalls are bounded by a slot capacity watermark check before proceeding. Link: https://lore.kernel.org/20260731193705.2902728-1-pratmal@google.com Signed-off-by: Pratyush Mallick Reviewed-by: SJ Park Acked-by: Lorenzo Stoakes (ARM) Acked-by: David Hildenbrand (Arm) Cc: Anshuman Khandual Cc: Brendan Jackman Cc: Greg Thelen Cc: Johannes Weiner Cc: Jonathan Corbet Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: SeongJae Park Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Zi Yan Signed-off-by: Andrew Morton

Merge branch 'mm-hotfixes-stable' into mm-stable in order to pick up

2026-08-05T02:15:12+00:00

vmscan.c changes which are required by "memcg: bail out proactive reclaim when memcg is dying".

mm: split out internal page_alloc.h

2026-07-31T02:40:41+00:00

internal.h is a bit bloated, seems like time for a page_alloc.h. Where it wasn't obvious, the heuristic for deciding what goes into this new header was "does it support/correspond to a definition in mm/page_alloc.c?" Only need to include it from ~20 .c files out of ~150 so this does seem like a genuine reduction in scopes, which is nice. And there's no circular internal.h<->page_alloc.h dependency, so it seems worthwhile to split this up before that inevitably emerges! Link: https://lore.kernel.org/20260703-alloc-trylock-v5-4-c87b714e19d3@google.com Signed-off-by: Brendan Jackman Suggested-by: "David Hildenbrand (Arm)" Link: https://lore.kernel.org/all/41e92bab-6882-401a-8de9-154adbdcfb36@kernel.org/ Reviewed-by: Vlastimil Babka (SUSE) Acked-by: Zi Yan Signed-off-by: Andrew Morton

mm/page_reporting: use system_freezable_wq to fix UAF during suspend

2026-07-29T00:37:33+00:00

During PM freeze (e.g. S3 suspend or S4 hibernation), device drivers like virtio_balloon reset their underlying virtio devices and delete their virtqueues via vdev->config->del_vqs(). However, page reporting work (page_reporting_process) was scheduled on the global system_wq. Because system_wq lacks the WQ_FREEZABLE flag, the PM freezer skips it, leaving page_reporting_process active during suspend. If pages are freed into the buddy allocator while suspending (for example, when core MM invokes the balloon shrinker during S4 hibernation image saving), page reporting triggers virtballoon_free_page_report() on deleted virtqueues, resulting in a Use-After-Free / General Protection Fault: [ 196.795226] general protection fault, probably for non-canonical address 0xaa1436fe70dae6df: 0000 [#1] SMP NOPTI [ 196.825967] Workqueue: events page_reporting_process [ 196.831038] RIP: 0010:virtqueue_add_split+0x233/0x4c0 [virtio_ring] [ 196.927073] virtballoon_free_page_report+0x3a/0xe0 [virtio_balloon] [ 196.946943] page_reporting_process+0x370/0x4f0 Fix this by switching page reporting work to system_freezable_wq. This ensures that the PM freezer pauses page_reporting_process before device drivers destroy their reporting virtqueues. Because the reporting worker is frozen, memory reclamation/freeing (e.g. via shrinker execution) can safely return pages to MM during freeze without triggering unfrozen reporting work on deleted virtqueues. This aligns with the driver's existing design. The comment in virtballoon_freeze() states: /* * The workqueue is already frozen by the PM core before this * function is called. */ Testing: I have verified these fixes using Google’s virtualization infrastructure by running continuous suspend/resume iterations (40+ cycles) while churning memory using stress-ng (`stress-ng --vm 4 --vm-bytes 60% --timeout 1`) to constantly create free pages for the buddy allocator. We also set the `page_reporting_order` parameter to 0 to make the page reporting worker highly sensitive, forcing it to pick up any 4K free pages. This confirmed that the UAF crashes are no longer reproducible. Link: https://lore.kernel.org/20260721005603.1710551-1-linkl@google.com Fixes: 36e66c554b5c ("mm: introduce Reported pages") Signed-off-by: Link Lin Suggested-by: David Hildenbrand (Arm) Suggested-by: Michael S. Tsirkin Acked-by: David Rientjes Acked-by: David Hildenbrand (Arm) Acked-by: Michael S. Tsirkin Cc: Alexander Duyck Cc: Greg Thelen Cc: James Houghton Cc: Jason Wang Cc: Jiaqi Yan Cc: Vlastimil Babka Cc: Xuan Zhuo Cc: Signed-off-by: Andrew Morton

mm: page_reporting: allow driver to set batch capacity

2026-07-09T22:48:56+00:00

At the moment, if a virtio balloon device has a page reporting vq but its size is < PAGE_REPORTING_CAPACITY (32), the balloon driver fails probe. But, there's no way for host to know this value, so it can easily create a smaller vq and suddenly adding the reporting capability to the device makes all of the driver fail. Not pretty. Add a capacity field to page_reporting_dev_info so drivers can control the maximum number of pages per report batch. In virtio-balloon, set the capacity to the reporting virtqueue size, letting page_reporting adapt to whatever the device provides. Capacity need not be a power of two. Code previously called out division by PAGE_REPORTING_CAPACITY as cheap since it was a power of 2, but no performance difference was observed with non-power-of-2 values. If capacity is 0 or exceeds PAGE_REPORTING_CAPACITY, it defaults to PAGE_REPORTING_CAPACITY. The 0 check and the clamping is done in page_reporting_register(), before the reporting work is scheduled, so we never get division by 0. Link: https://lore.kernel.org/444c24cf39f3f3620fc90ef4695bd6b0979f4c4b.1783232420.git.mst@redhat.com Fixes: b0c504f15471 ("virtio-balloon: add support for providing free page reports to host") Signed-off-by: Michael S. Tsirkin Assisted-by: Claude:claude-opus-4-6 Acked-by: David Hildenbrand (Arm) Reviewed-by: Gregory Price Acked-by: Zi Yan Reviewed-by: Pankaj Gupta Cc: Alexander Duyck Cc: Brendan Jackman Cc: Eugenio Pérez Cc: Jason Wang Cc: Johannes Weiner Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Xuan Zhuo Signed-off-by: Andrew Morton

mm/page_reporting: change page_reporting_order to PAGE_REPORTING_ORDER_UNSPECIFIED

2026-04-05T20:53:17+00:00

page_reporting_order when uninitialised, holds a magic number -1. Since we now maintain PAGE_REPORTING_ORDER_UNSPECIFIED as -1, which is also a flag, set page_reporting_order to this flag. Link: https://lkml.kernel.org/r/20260303113032.3008371-6-yuvraj.sakshith@oss.qualcomm.com Signed-off-by: Yuvraj Sakshith Acked-by: David Hildenbrand (Arm) Reviewed-by: Michael Kelley Acked-by: Michael S. Tsirkin Cc: Brendan Jackman Cc: Dexuan Cui Cc: Eugenio Pérez Cc: Haiyang Zhang Cc: Jason Wang Cc: Johannes Weiner Cc: K. Y. Srinivasan Cc: Liam Howlett Cc: Long Li Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Wei Liu Cc: Xuan Zhuo Cc: Zi Yan Signed-off-by: Andrew Morton

mm/page_reporting: add PAGE_REPORTING_ORDER_UNSPECIFIED

2026-04-05T20:53:17+00:00

Patch series "Allow order zero pages in page reporting", v4. Today, page reporting sets page_reporting_order in two ways: (1) page_reporting.page_reporting_order cmdline parameter (2) Driver can pass order while registering itself. In both cases, order zero is ignored by free page reporting because it is used to set page_reporting_order to a default value, like MAX_PAGE_ORDER. In some cases we might want page_reporting_order to be zero. For instance, when virtio-balloon runs inside a guest with tiny memory (say, 16MB), it might not be able to find a order 1 page (or in the worst case order MAX_PAGE_ORDER page) after some uptime. Page reporting should be able to return order zero pages back for optimal memory relinquishment. This patch changes the default fallback value from '0' to '-1' in all possible clients of free page reporting (hv_balloon and virtio-balloon) together with allowing '0' as a valid order in page_reporting_register(). This patch (of 5): Drivers can pass order of pages to be reported while registering itself. Today, this is a magic number, 0. Label this with PAGE_REPORTING_ORDER_UNSPECIFIED and check for it when the driver is being registered. This macro will be used in relevant drivers next. [akpm@linux-foundation.org: tweak whitespace, per David] Link: https://lkml.kernel.org/r/20260303113032.3008371-1-yuvraj.sakshith@oss.qualcomm.com Link: https://lkml.kernel.org/r/20260303113032.3008371-2-yuvraj.sakshith@oss.qualcomm.com Signed-off-by: Yuvraj Sakshith Acked-by: David Hildenbrand (Arm) Reviewed-by: Michael Kelley Acked-by: Michael S. Tsirkin Cc: Brendan Jackman Cc: Dexuan Cui Cc: Eugenio Pérez Cc: Haiyang Zhang Cc: Jason Wang Cc: Johannes Weiner Cc: K. Y. Srinivasan Cc: Liam Howlett Cc: Long Li Cc: Lorenzo Stoakes (Oracle) Cc: Michal Hocko Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Wei Liu Cc: Xuan Zhuo Cc: Zi Yan Signed-off-by: Andrew Morton

Convert 'alloc_obj' family to use the new default GFP_KERNEL argument

2026-02-22T01:09:51+00:00

This was done entirely with mindless brute force, using git grep -l '\

treewide: Replace kmalloc with kmalloc_obj for non-scalar types

2026-02-21T09:02:28+00:00

This is the result of running the Coccinelle script from scripts/coccinelle/api/kmalloc_objs.cocci. The script is designed to avoid scalar types (which need careful case-by-case checking), and instead replace kmalloc-family calls that allocate struct or union object instances: Single allocations: kmalloc(sizeof(TYPE), ...) are replaced with: kmalloc_obj(TYPE, ...) Array allocations: kmalloc_array(COUNT, sizeof(TYPE), ...) are replaced with: kmalloc_objs(TYPE, COUNT, ...) Flex array allocations: kmalloc(struct_size(PTR, FAM, COUNT), ...) are replaced with: kmalloc_flex(*PTR, FAM, COUNT, ...) (where TYPE may also be *VAR) The resulting allocations no longer return "void *", instead returning "TYPE *". Signed-off-by: Kees Cook

mm: fix minor spelling mistakes in comments

2026-01-21T03:24:48+00:00

Correct several typos in comments across files in mm/ [akpm@linux-foundation.org: also fix comment grammar, per SeongJae] Link: https://lkml.kernel.org/r/20251218150906.25042-1-klourencodev@gmail.com Signed-off-by: Kevin Lourenco Reviewed-by: SeongJae Park Acked-by: David Hildenbrand (Red Hat) Reviewed-by: Lorenzo Stoakes Signed-off-by: Andrew Morton