From 1833ce36b35426504c64600c94f322437ea44bb2 Mon Sep 17 00:00:00 2001 From: Breno Leitao Date: Thu, 16 Jul 2026 06:42:18 -0700 Subject: [PATCH 01/12] mm: memcg: initialize *locked in memcg1_oom_prepare() stub mem_cgroup_oom() passes an uninitialized "locked" to memcg1_oom_prepare() and reads it back in memcg1_oom_finish(): bool locked, ret; ... if (!memcg1_oom_prepare(memcg, &locked)) return false; ret = mem_cgroup_out_of_memory(memcg, mask, order); memcg1_oom_finish(memcg, locked); This relies on memcg1_oom_prepare() setting *locked whenever it returns true. The CONFIG_MEMCG_V1=y version does, but the stub used when CONFIG_MEMCG_V1=n returns true without touching *locked, so memcg1_oom_finish() consumes an uninitialized value. On a memcg OOM this is reported by UBSAN: UBSAN: invalid-load in mm/memcontrol.c:1932:27 load of value 0 is not a valid value for type 'bool' (aka '_Bool') Initialize *locked to false in the stub; with cgroup v1 compiled out there is no OOM lock to take. Link: https://lore.kernel.org/20260716-memcg-oom-uninit-locked-v2-1-63631d878eb4@debian.org Fixes: e93d4166b40a ("mm: memcg: put cgroup v1-specific code under a config option") Signed-off-by: Breno Leitao Reviewed-by: Joshua Hahn Acked-by: Johannes Weiner Reviewed-by: SeongJae Park Acked-by: Shakeel Butt Cc: Michal Hocko Cc: Muchun Song Cc: Roman Gushchin Cc: Shakeel Butt Cc: Signed-off-by: Andrew Morton --- mm/memcontrol-v1.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/mm/memcontrol-v1.h b/mm/memcontrol-v1.h index f92f81108d5e..4fa6e2bc8413 100644 --- a/mm/memcontrol-v1.h +++ b/mm/memcontrol-v1.h @@ -107,7 +107,11 @@ static inline void memcg1_remove_from_trees(struct mem_cgroup *memcg) {} static inline void memcg1_soft_limit_reset(struct mem_cgroup *memcg) {} static inline void memcg1_css_offline(struct mem_cgroup *memcg) {} -static inline bool memcg1_oom_prepare(struct mem_cgroup *memcg, bool *locked) { return true; } +static inline bool memcg1_oom_prepare(struct mem_cgroup *memcg, bool *locked) +{ + *locked = false; + return true; +} static inline void memcg1_oom_finish(struct mem_cgroup *memcg, bool locked) {} static inline void memcg1_oom_recover(struct mem_cgroup *memcg) {} From 4bd0c3515a041d9aa1558c4e8ea0efdb56509f9a Mon Sep 17 00:00:00 2001 From: Nico Pache Date: Fri, 17 Jul 2026 00:44:59 -0600 Subject: [PATCH 02/12] mm: decrement MTHP_STAT_NR_ANON in free_zone_device_folio() Patch series "mm: fix PMD level mTHP accounting bugs", v2. While running selftests I noticed the PMD level per-mTHP stats (nr_anon) remained elevated after each run. After further investigation I noticed this accounting error occurs for both the migration.private_anon_htlb_test and the HMM tests. In the HMM case this is due to folio_add_new_anon_rmap() incrementing the mTHP stats, but never containing a corresponding decrement in free_zone_device_folio(). We solve this by making sure to decrement the counter when freeing device memory. In the migration case, we are incrementing this counter without first checking whether this folio is a hugetlb folio, which relies on a separate accounting system. We solve this by adding the proper hugetlb check before incrementing this counter. With these changes in place, the two tests no longer cause elevated PMD level accounting issues. This patch (of 2): When a zone device folio is mapped as anonymous, folio_add_new_anon_rmap() increments MTHP_STAT_NR_ANON. The corresponding decrement lives in __free_pages_prepare() in page_alloc.c, but zone device folios are freed via free_zone_device_folio() which never calls __free_pages_prepare(). This causes nr_anon to remain permanently elevated after zone device folios are freed. Add the missing mod_mthp_stat() decrement to free_zone_device_folio() so that the counter is properly balanced. Link: https://lore.kernel.org/20260717064502.1980173-1-npache@redhat.com Link: https://lore.kernel.org/20260717064502.1980173-2-npache@redhat.com Fixes: 5d65c8d758f2 ("mm: count the number of anonymous THPs per size") Co-developed-by: David Hildenbrand Signed-off-by: David Hildenbrand Signed-off-by: Nico Pache Reviewed-by: Zi Yan Cc: Alistair Popple Cc: Barry Song Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Oscar Salvador Cc: Rakie Kim Cc: Baolin Wang Signed-off-by: Andrew Morton --- mm/memremap.c | 1 + 1 file changed, 1 insertion(+) diff --git a/mm/memremap.c b/mm/memremap.c index 81766d822400..accba23aef28 100644 --- a/mm/memremap.c +++ b/mm/memremap.c @@ -425,6 +425,7 @@ void free_zone_device_folio(struct folio *folio) mem_cgroup_uncharge(folio); if (folio_test_anon(folio)) { + mod_mthp_stat(folio_order(folio), MTHP_STAT_NR_ANON, -1); for (i = 0; i < nr; i++) __ClearPageAnonExclusive(folio_page(folio, i)); } From d09a8fd521476950079ee01a1408e6f5b7a0aa3e Mon Sep 17 00:00:00 2001 From: Nico Pache Date: Fri, 17 Jul 2026 00:45:00 -0600 Subject: [PATCH 03/12] mm/migrate: exclude hugetlb folios from MTHP_STAT_NR_ANON accounting MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit __folio_migrate_mapping() increments MTHP_STAT_NR_ANON for the destination folio when `folio_test_anon(folio) && folio_test_large(folio)` is true. However, hugetlb folios satisfy both conditions despite having a completely separate accounting system — they use hugetlb_add_anon_rmap() which does not touch mTHP stats, and their free path also bypasses the mTHP decrement in __free_pages_prepare(). This causes MTHP_STAT_NR_ANON to be incremented on each hugetlb migration without a corresponding decrement, permanently inflating the nr_anon counter. Add a !folio_test_hugetlb() check to __folio_migrate_mapping() so that only actual mTHP folios are counted. Link: https://lore.kernel.org/20260717064502.1980173-3-npache@redhat.com Fixes: 5d65c8d758f2 ("mm: count the number of anonymous THPs per size") Co-developed-by: David Hildenbrand Signed-off-by: David Hildenbrand Signed-off-by: Nico Pache Reviewed-by: Zi Yan Reviewed-by: Baolin Wang Cc: Alistair Popple Cc: Barry Song Cc: Byungchul Park Cc: Gregory Price Cc: "Huang, Ying" Cc: Joshua Hahn Cc: Lorenzo Stoakes Cc: Matthew Brost Cc: Matthew Wilcox (Oracle) Cc: Oscar Salvador Cc: Rakie Kim Signed-off-by: Andrew Morton --- mm/migrate.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/migrate.c b/mm/migrate.c index d9b23909d716..dd15a84b2a52 100644 --- a/mm/migrate.c +++ b/mm/migrate.c @@ -590,7 +590,8 @@ static int __folio_migrate_mapping(struct address_space *mapping, /* No turning back from here */ newfolio->index = folio->index; newfolio->mapping = folio->mapping; - if (folio_test_anon(folio) && folio_test_large(folio)) + if (folio_test_anon(folio) && folio_test_large(folio) && + !folio_test_hugetlb(folio)) mod_mthp_stat(folio_order(folio), MTHP_STAT_NR_ANON, 1); if (folio_test_swapbacked(folio)) __folio_set_swapbacked(newfolio); From 45ebe4540817cb540a59e4dc04014ac5dddc9990 Mon Sep 17 00:00:00 2001 From: Jiakai Xu Date: Thu, 16 Jul 2026 11:53:25 +0000 Subject: [PATCH 04/12] riscv/mm: use physical alignment for vmemmap_start_pfn RISC-V computes vmemmap_start_pfn by rounding phys_ram_base down to VMEMMAP_ADDR_ALIGN. That alignment must therefore be expressed in the physical-address domain. Commit 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size") attempted to account for the maximal folio alignment by feeding MAX_FOLIO_VMEMMAP_ALIGN directly into VMEMMAP_ADDR_ALIGN. However, MAX_FOLIO_VMEMMAP_ALIGN is measured in bytes of struct page storage, whereas VMEMMAP_ADDR_ALIGN is used to align a physical address. The mask-based compound_info encoding requires pfn_to_page(0) to be naturally aligned to MAX_FOLIO_VMEMMAP_ALIGN. Commit 9f94db4c7eaa ("mm/sparse: check memmap alignment for compound_info_has_mask()") added a check for that requirement and exposed the unit mismatch on systems such as QEMU virt, where the DRAM base is not aligned to MAX_FOLIO_NR_PAGES * PAGE_SIZE. Here is the log: [ 0.000000][ C0] ------------[ cut here ]------------ [ 0.000000][ C0] WARNING: mm/sparse.c:365 at sparse_init+0x58a/0x6fe, CPU#0: swapper/0 [ 0.000000][ C0] Modules linked in: [ 0.000000][ C0] CPU: 0 UID: 0 PID: 0 Comm: swapper Not tainted 7.2.0-rc3-g1d8304bdd65f #2 PREEMPT [ 0.000000][ C0] Hardware name: riscv-virtio,qemu (DT) [ 0.000000][ C0] epc : sparse_init+0x58a/0x6fe [ 0.000000][ C0] ra : sparse_init+0x58a/0x6fe [ 0.000000][ C0] epc : ffffffff86851c88 ra : ffffffff86851c88 sp : ffffffff88807a30 [ 0.000000][ C0] gp : ffffffff8a3bf240 tp : ffffffff88842080 t0 : ff600000ffab6000 [ 0.000000][ C0] t1 : 000000017fab6000 t2 : 65203a6573726363 s0 : ffffffff88807bc0 [ 0.000000][ C0] s1 : 000000000e000000 a0 : 0000000000000007 a1 : 0000000000000000 [ 0.000000][ C0] a2 : 0000000000000002 a3 : ffffffff86851c88 a4 : 0000000000000000 [ 0.000000][ C0] a5 : ffffffff88843080 a6 : 0000000000000003 a7 : 0000000000000000 [ 0.000000][ C0] s2 : ff60000000000000 s3 : 0040000000000000 s4 : 0004000000000000 [ 0.000000][ C0] s5 : ffffffff8a4d92e0 s6 : ff600000ffab55e0 s7 : ffffffff88384d00 [ 0.000000][ C0] s8 : 0000000000000003 s9 : ffffffff88384cc1 s10: ffffffff88384cc0 [ 0.000000][ C0] s11: ffffffff8a4daae0 t3 : ffffffff915e8b20 t4 : ffffffff915e8b20 [ 0.000000][ C0] t5 : ffffffff915e8b20 t6 : ffffffff915e8bc8 ssp : 0000000000000000 [ 0.000000][ C0] status: 0000000200000100 badaddr: ffffffff86851c88 cause: 0000000000000003 [ 0.000000][ C0] [] sparse_init+0x58a/0x6fe [ 0.000000][ C0] [] mm_core_init_early+0x116/0x1e30 [ 0.000000][ C0] [] start_kernel+0xd2/0x848 Convert MAX_FOLIO_VMEMMAP_ALIGN to the equivalent physical alignment before using it in VMEMMAP_ADDR_ALIGN. This keeps the existing round_down() logic while making the resulting vmemmap base satisfy the mask-alignment requirement. Link: https://lore.kernel.org/20260716115326.3466926-1-xujiakai2025@iscas.ac.cn Fixes: 476849b0fba4 ("riscv/mm: align vmemmap to maximal folio size") Signed-off-by: Jiakai Xu Reviewed-by: Kiryl Shutsemau (Meta) Cc: Albert Ou Cc: Alexandre Ghiti Cc: David Hildenbrand Cc: Guo Ren Cc: Mike Rapoport Cc: Muchun Song Cc: Nam Cao Cc: Palmer Dabbelt Cc: Vishal Moola (Oracle) Assisted-by: YuanSheng:DeepSeek-V4-Flash Cc: Signed-off-by: Andrew Morton --- arch/riscv/mm/init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/arch/riscv/mm/init.c b/arch/riscv/mm/init.c index 3e450890be07..422efa11824b 100644 --- a/arch/riscv/mm/init.c +++ b/arch/riscv/mm/init.c @@ -63,7 +63,8 @@ EXPORT_SYMBOL(phys_ram_base); #ifdef CONFIG_SPARSEMEM_VMEMMAP #define VMEMMAP_ADDR_ALIGN max(1ULL << SECTION_SIZE_BITS, \ - MAX_FOLIO_VMEMMAP_ALIGN) + PFN_PHYS(MAX_FOLIO_VMEMMAP_ALIGN / \ + sizeof(struct page))) unsigned long vmemmap_start_pfn __ro_after_init; EXPORT_SYMBOL(vmemmap_start_pfn); From e923bd21058ea02fd0dcd3549d151d143fd036e5 Mon Sep 17 00:00:00 2001 From: "Kiryl Shutsemau (Meta)" Date: Thu, 16 Jul 2026 10:54:24 +0100 Subject: [PATCH 05/12] mm/huge_memory: unlock i_mmap_rwsem before releasing after-split folios __folio_split() keeps dereferencing the mapping after the split: shmem_uncharge(mapping->host) and remap_page() while the folios are still frozen/locked, and i_mmap_unlock_read(mapping) at the very end, after the after-split folios have been unlocked and freed. Nothing holds an inode reference across that. The split relies on @folio -- which the beyond-EOF drop loop never removes, as it starts at folio_next(folio) -- staying locked and in the page cache to hold off eviction. But the unlock loop unlocks @folio before i_mmap_unlock_read() runs. If the caller's @lock_at is a tail beyond EOF, as memory_failure() passes when splitting a poisoned tail of a shmem THP that reaches past i_size during truncation, it too is gone from the page cache; so once @folio is unlocked no locked, in-cache folio pins the inode, and a concurrent final iput() can evict and RCU-free it before i_mmap_unlock_read() touches i_mmap_rwsem: BUG: KASAN: slab-use-after-free in __up_read+0x634/0x790 i_mmap_unlock_read include/linux/fs.h:537 [inline] __folio_split+0x732/0x1640 mm/huge_memory.c:4100 try_to_split_thp_page+0xab/0x390 mm/memory-failure.c:1675 memory_failure+0x1394/0x26e0 mm/memory-failure.c:2470 Freed by task 4601: shmem_free_in_core_inode+0x54/0xb0 mm/shmem.c:5177 evict+0x57f/0xac0 fs/inode.c:870 Do every mapping dereference while @folio still pins the inode: drop i_mmap_rwsem right after remap_page(), before the loop that unlocks and frees the after-split folios, and clear @mapping so the exit path does not unlock it again. shmem_uncharge() and remap_page() already run before that point, so after this nothing past the unlock loop touches the inode or the mapping. This is now a rule the split depends on, alongside keeping @folio frozen until the page cache is updated: no inode or mapping dereference once the after-split folios start being unlocked. Link: https://lore.kernel.org/20260716095424.471052-1-kirill@shutemov.name Fixes: baa355fd3314 ("thp: file pages support for split_huge_page()") Signed-off-by: Kiryl Shutsemau (Meta) Reported-by: Hao Zhang Closes: https://lore.kernel.org/linux-mm/20260710071344.GA106129@zh-pc Co-developed-by: Hao Zhang Signed-off-by: Hao Zhang Acked-by: David Hildenbrand (Arm) Reviewed-by: Zi Yan Reviewed-by: Baolin Wang Reviewed-by: Miaohe Lin Cc: Baolin Wang Cc: Barry Song Cc: Dev Jain Cc: Lance Yang Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Naoya Horiguchi Cc: Nico Pache Cc: Ryan Roberts Cc: Signed-off-by: Andrew Morton --- mm/huge_memory.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index 032702a4637b..58cabe6af33d 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -4113,6 +4113,18 @@ static int __folio_split(struct folio *folio, unsigned int new_order, remap_page(folio, 1 << old_order, ttu_flags); + /* + * Drop the mapping while the inode is still pinned. @folio stays + * locked and present in the page cache until the loop below, so + * eviction cannot free the inode yet; @lock_at is not enough, it may + * be a tail beyond EOF that the split already dropped from the page + * cache. Nothing past this point may touch the inode or the mapping. + */ + if (mapping) { + i_mmap_unlock_read(mapping); + mapping = NULL; + } + /* * Unlock all after-split folios except the one containing * @lock_at page. If @folio is not split, it will be kept locked. From 598356522b3a7c337fbf643561ee9b2ba868840e Mon Sep 17 00:00:00 2001 From: Burak Emir Date: Sat, 18 Jul 2026 17:13:03 +0200 Subject: [PATCH 06/12] MAINTAINERS: update address for Burak Emir Update MAINTAINERS and .mailmap to point to my gmail.com address: burak.emir@gmail.com. Link: https://lore.kernel.org/20260718151303.2649-1-burak.emir@gmail.com Signed-off-by: Burak Emir Cc: Alice Ryhl Cc: Jakub Kacinski Cc: Martin Kepplinger Cc: Yury Norov (NVIDIA) Signed-off-by: Andrew Morton --- .mailmap | 1 + MAINTAINERS | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index a8be42f87e02..de68ca3cbd23 100644 --- a/.mailmap +++ b/.mailmap @@ -176,6 +176,7 @@ Brian Cain Brian King Brian Silverman Bryan Tan +Burak Emir Cai Huoqing Casey Connolly Casey Connolly diff --git a/MAINTAINERS b/MAINTAINERS index 2f9472c1a090..39c9413355f3 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -4634,7 +4634,7 @@ F: rust/helpers/cpumask.c BITMAP API [RUST] M: Alice Ryhl -M: Burak Emir +M: Burak Emir R: Yury Norov S: Maintained F: lib/find_bit_benchmark_rust.rs From 1fcac73551425c6924cca5cc29f10a5caf80907b Mon Sep 17 00:00:00 2001 From: Peter Collingbourne Date: Sat, 18 Jul 2026 10:29:23 -0700 Subject: [PATCH 07/12] arm64, mailmap: update email address for Peter Collingbourne I am no longer at Google. Link: https://lore.kernel.org/20260718172923.8297-1-peter@pcc.me.uk Signed-off-by: Peter Collingbourne Cc: Catalin Marinas Cc: Ian Rogers Cc: Jakub Kacinski Cc: Martin Kepplinger Cc: Nick Desaulniers Cc: Will Deacon Signed-off-by: Andrew Morton --- .mailmap | 1 + arch/arm64/kernel/pi/relocate.c | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index de68ca3cbd23..c9c3a6b2b1f5 100644 --- a/.mailmap +++ b/.mailmap @@ -696,6 +696,7 @@ Paulo Alcantara Paulo Alcantara Pavankumar Kondeti Peter A Jonsson +Peter Collingbourne Peter Hilber Peter Oruba Peter Oruba diff --git a/arch/arm64/kernel/pi/relocate.c b/arch/arm64/kernel/pi/relocate.c index 2407d2696398..82592f3a5c1c 100644 --- a/arch/arm64/kernel/pi/relocate.c +++ b/arch/arm64/kernel/pi/relocate.c @@ -1,7 +1,7 @@ // SPDX-License-Identifier: GPL-2.0-only // Copyright 2023 Google LLC // Authors: Ard Biesheuvel -// Peter Collingbourne +// Peter Collingbourne #include #include From 8c7372c5b155fff151a111f03ec0fb87c4c063fe Mon Sep 17 00:00:00 2001 From: "Nico Pache (Red Hat)" Date: Tue, 21 Jul 2026 04:18:11 -0600 Subject: [PATCH 08/12] MAINTAINERS: update Nico Pache's email address Switch my entry in MAINTAINERS and .mailmap to my @linux.dev email address Link: https://lore.kernel.org/20260721101811.115954-1-nico.pache@linux.dev Signed-off-by: Nico Pache Signed-off-by: Nico Pache (Red Hat) Acked-by: David Hildenbrand (Arm) Signed-off-by: Andrew Morton --- .mailmap | 1 + MAINTAINERS | 2 +- 2 files changed, 2 insertions(+), 1 deletion(-) diff --git a/.mailmap b/.mailmap index c9c3a6b2b1f5..ca6dc2575802 100644 --- a/.mailmap +++ b/.mailmap @@ -649,6 +649,7 @@ Nicholas Piggin Nicholas Piggin Nicholas Piggin Nicolas Ferre +Nico Pache Nicolas Pitre Nicolas Pitre Nicolas Saenz Julienne diff --git a/MAINTAINERS b/MAINTAINERS index 39c9413355f3..48b2baa1541f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -17253,7 +17253,7 @@ M: Lorenzo Stoakes R: Zi Yan R: Baolin Wang R: Liam R. Howlett -R: Nico Pache +R: Nico Pache R: Ryan Roberts R: Dev Jain R: Barry Song From dc37771a43d4a8762f05060c28463b0c20e6dc9b Mon Sep 17 00:00:00 2001 From: Richard Chang Date: Mon, 20 Jul 2026 04:41:03 +0000 Subject: [PATCH 09/12] mm: vmscan: abort proactive reclaim early when freezing for suspend MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Proactive reclaim (triggered via memory.reclaim or node sysfs) checks for pending signals in its outer loop in user_proactive_reclaim(). However, the inner reclaim loops—specifically scanning cgroups in shrink_many() and evicting/aging folios in try_to_shrink_lruvec()—can run for a long time before returning to the outer loop, especially on systems with many cgroups or large memory sizes. During system suspend, the PM freezer attempts to freeze all tasks by sending fake signals (setting TIF_SIGPENDING). Because the inner loops do not check for pending signals, the proactive reclaim task can remain stuck in kernel space for seconds, failing to enter the refrigerator in a timely manner. This leads to suspend failures due to freeze timeouts, a behavior observed on Android devices. This latency issue is specific to proactive reclaim because of its large, user-defined reclaim targets (could be gigabytes). Since commit 287d5fedb377 ("mm: memcg: use larger batches for proactive reclaim"), proactive reclaim uses larger decaying batch sizes (starting at 1/4 of the remaining target) to maintain throughput. This keeps the task in the inner reclaim loop for extended periods. In contrast, reactive reclaim (global/memcg) uses small targets (SWAP_CLUSTER_MAX, typically 32 pages), allowing it to return to the outer loop and check signals frequently. To fix this, add a signal_pending() check to should_abort_scan() for proactive reclaim paths. Since should_abort_scan() is called within the inner scanning and eviction loops, this allows proactive reclaim to abort early and return to the outer loop in user_proactive_reclaim(). Additionally, return -ERESTARTSYS instead of -EINTR in user_proactive_reclaim(). When interrupted by system suspend, returning -ERESTARTSYS allows the task to enter the refrigerator and automatically restart the syscall upon resume, making the freezer transparent to userspace. For real signals, the signal layer will either restart the syscall (if SA_RESTART is set) or return -EINTR to userspace. This fix specifically targets Multi-Gen LRU (MGLRU). Classic LRU's scan targets per iteration are strictly bounded by get_scan_count(), which ensures it returns to the outer loop more frequently. The check in should_abort_scan() is limited to proactive reclaim (sc->proactive) to avoid inadvertently affecting reactive reclaim paths, and is wrapped in unlikely() as it is a slow path. Link: https://lore.kernel.org/20260720044103.905191-1-richardycc@google.com Fixes: 287d5fedb377 ("mm: memcg: use larger batches for proactive reclaim") Fixes: 94968384dde1 ("memcg: introduce per-memcg reclaim interface") Suggested-by: Michal Hocko Suggested-by: Oleg Nesterov Signed-off-by: Richard Chang Acked-by: Michal Hocko Cc: Axel Rasmussen Cc: Barry Song Cc: David Hildenbrand Cc: Johannes Weiner Cc: Kairui Song Cc: Lorenzo Stoakes Cc: Martin Liu Cc: Minchan Kim Cc: Shakeel Butt Cc: Suren Baghdasaryan Cc: T.J. Mercier Cc: Wei Xu Cc: Yuanchu Xie Signed-off-by: Andrew Morton --- mm/vmscan.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 1a142c58700d..56708d1d2dfd 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4926,6 +4926,9 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc) int i; enum zone_watermarks mark; + if (unlikely(sc->proactive && signal_pending(current))) + return true; + if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order))) return true; @@ -7906,8 +7909,15 @@ int user_proactive_reclaim(char *buf, unsigned long batch_size = (nr_to_reclaim - nr_reclaimed) / 4; unsigned long reclaimed; + /* + * Return -ERESTARTSYS to allow the freezer to interrupt the + * task. The syscall will be transparently restarted upon + * resume. For real signals, it either restarts the syscall + * (if SA_RESTART is set) or is converted to -EINTR by the + * signal layer. + */ if (signal_pending(current)) - return -EINTR; + return -ERESTARTSYS; /* * This is the final attempt, drain percpu lru caches in the From 0b45f6927a14914ff685fe0e6f9d11232a1e03df Mon Sep 17 00:00:00 2001 From: Link Lin Date: Tue, 21 Jul 2026 00:55:33 +0000 Subject: [PATCH 10/12] mm/page_reporting: use system_freezable_wq to fix UAF during suspend MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/mm/page_reporting.c b/mm/page_reporting.c index 942e84b6908a..3e30731b940e 100644 --- a/mm/page_reporting.c +++ b/mm/page_reporting.c @@ -80,7 +80,8 @@ __page_reporting_request(struct page_reporting_dev_info *prdev) * now we are limiting this to running no more than once every * couple of seconds. */ - schedule_delayed_work(&prdev->work, PAGE_REPORTING_DELAY); + queue_delayed_work(system_freezable_wq, &prdev->work, + PAGE_REPORTING_DELAY); } /* notify prdev of free page reporting request */ @@ -340,7 +341,8 @@ static void page_reporting_process(struct work_struct *work) */ state = atomic_cmpxchg(&prdev->state, state, PAGE_REPORTING_IDLE); if (state == PAGE_REPORTING_REQUESTED) - schedule_delayed_work(&prdev->work, PAGE_REPORTING_DELAY); + queue_delayed_work(system_freezable_wq, &prdev->work, + PAGE_REPORTING_DELAY); } static DEFINE_MUTEX(page_reporting_mutex); From 8f6f9fd93cd7a5dd607ad5cd910476dd68fff3ed Mon Sep 17 00:00:00 2001 From: Chris Gellermann Date: Wed, 22 Jul 2026 15:02:45 +0200 Subject: [PATCH 11/12] selftests/clone3: fix wild pointer access of getline due to missing init Patch series "selftests: Add missing initalization of pointer passed to getline", v2. This patch (of 2): Clone3_set_tid uses getline(&line, ...) in a loop to read the child's process status. The code expects that getline allocates the buffer for the line on the first loop iteration. According to the Open Group Spec[1], char *line has to be null pointer for this: > ssize_t getline(char **restrict lineptr, ...); > If *lineptr is a null pointer or if the object pointed to by *lineptr > is of insufficient size, an object shall be allocated as if by malloc() > or the object shall be reallocated as if by realloc()[...]. However, char *line is only declared, leading to an undefined value that is potentially non-null. In an example run with Musl v1.2.6, the realloc call[2] of getdelim, which implements getline, triggers a segfault: ./run_kselftest.sh --test clone3:clone3_set_tid [ 1366.165898] kselftest: Running tests in clone3 ... [ 1367.799244] clone3_set_tid[811]: unhandled signal 11 code 0x1 at 0x0000000000000000 in libc.so[68184,3fbf69f000+4c000] [ 1367.802808] CPU: 0 UID: 0 PID: 811 Comm: clone3_set_tid Not tainted .. [ 1367.804188] epc: 0x0000003fbf6b0184 [ 1367.804188] ra : 0x0000003fbf6d4664 [ 1367.804188] sp : 0x0000003fce5f2e40 [ 1367.805314] gp : 0x0000002aaab0dfb8 [ 1367.805314] tp : 0x0000003fbf6f14a8 [ 1367.805314] t0 : 0x0000003fbf63d000 ... Looking at the realloc implementation, Musl mallocs for a null pointer memory. But for a non-null pointer, it assumes it's passed a valid pointer to the heap and tries to access its meta-data. This leads to the segfault we see: void *realloc(void *p, size_t n) { if (!p) return malloc(n); if (size_overflows(n)) return 0; struct meta *g = get_meta(p); ... } Fix this by properly initializing the line pointer to NULL. Link: https://lore.kernel.org/20260722130246.2135563-1-christian.gellermann@codasip.com Link: https://lore.kernel.org/20260722130246.2135563-2-christian.gellermann@codasip.com Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/getline.html [1] Link: https://git.musl-libc.org/cgit/musl/tree/src/stdio/getdelim.c#n38 [2] Fixes: 41585bbeeef9 ("selftests: add tests for clone3() with *set_tid") Signed-off-by: Chris Gellermann Acked-by: David Hildenbrand (arm) Reviewed-by: Lorenzo Stoakes Cc: Christian Brauner Cc: Liam R. Howlett Cc: Lorenzo Stoakes Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton --- tools/testing/selftests/clone3/clone3_set_tid.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/clone3/clone3_set_tid.c b/tools/testing/selftests/clone3/clone3_set_tid.c index 5c944aee6b41..485efa7c9eed 100644 --- a/tools/testing/selftests/clone3/clone3_set_tid.c +++ b/tools/testing/selftests/clone3/clone3_set_tid.c @@ -141,7 +141,7 @@ int main(int argc, char *argv[]) { FILE *f; char buf; - char *line; + char *line = NULL; int status; int ret = -1; size_t len = 0; From 9f1d75a4ce04095afdb63d8e540092ff8151dacf Mon Sep 17 00:00:00 2001 From: Chris Gellermann Date: Wed, 22 Jul 2026 15:02:46 +0200 Subject: [PATCH 12/12] selftests/mm: fix potential wild pointer access of getline due to missing init This is another occurrence of using getline where the code assumes that getline allocates memory to store the line, but the pointer passed to it is uninitialized and potentially a non-null pointer. This violates the Open Group Spec[1] and caused a segfault in a similar situation in selftest/clone3/clone3_set_tid. Fix it by initializing the line pointer to NULL. The issue has been found by simply grepping through the selftest code after running into the issue in clone3_set_tid. Whether it segfaults in its current state is unknown to me. But it's good to be addressed due to defensive reasons. Link: https://lore.kernel.org/20260722130246.2135563-3-christian.gellermann@codasip.com Link: https://pubs.opengroup.org/onlinepubs/9799919799/functions/getline.html [1] Fixes: 26b4224d9961 ("selftests: expanding more mlock selftest") Signed-off-by: Chris Gellermann Acked-by: David Hildenbrand (arm) Reviewed-by: Lorenzo Stoakes Cc: Christian Brauner Cc: Liam R. Howlett Cc: Michal Hocko Cc: Mike Rapoport Cc: Shuah Khan Cc: Suren Baghdasaryan Cc: Vlastimil Babka Cc: Signed-off-by: Andrew Morton --- tools/testing/selftests/mm/mlock-random-test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/testing/selftests/mm/mlock-random-test.c b/tools/testing/selftests/mm/mlock-random-test.c index 9d349c151360..16294bc7dae6 100644 --- a/tools/testing/selftests/mm/mlock-random-test.c +++ b/tools/testing/selftests/mm/mlock-random-test.c @@ -84,7 +84,7 @@ int get_proc_locked_vm_size(void) int get_proc_page_size(unsigned long addr) { FILE *smaps; - char *line; + char *line = NULL; unsigned long mmupage_size = 0; size_t size;