linux-kernel - Re: [syzbot ci] Re: Eliminate Dying Memory Cgroup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aQFeMG8WEvrWaNf0@hyeyoo>
Date: Wed, 29 Oct 2025 09:22:08 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: syzbot ci <syzbot+cie7d8f1fc805fcd7a@...kaller.appspotmail.com>
Cc: akpm@...ux-foundation.org, axelrasmussen@...gle.com,
        cgroups@...r.kernel.org, chengming.zhou@...ux.dev, david@...hat.com,
        hannes@...xchg.org, hughd@...gle.com, imran.f.khan@...cle.com,
        kamalesh.babulal@...cle.com, linux-kernel@...r.kernel.org,
        linux-mm@...ck.org, lorenzo.stoakes@...cle.com, mhocko@...e.com,
        muchun.song@...ux.dev, nphamcs@...il.com, qi.zheng@...ux.dev,
        roman.gushchin@...ux.dev, shakeel.butt@...ux.dev,
        songmuchun@...edance.com, weixugc@...gle.com, yuanchu@...gle.com,
        zhengqi.arch@...edance.com, ziy@...dia.com, syzbot@...ts.linux.dev,
        syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot ci] Re: Eliminate Dying Memory Cgroup

On Tue, Oct 28, 2025 at 01:58:33PM -0700, syzbot ci wrote:
> syzbot ci has tested the following series
> 
> [v1] Eliminate Dying Memory Cgroup
> https://lore.kernel.org/all/cover.1761658310.git.zhengqi.arch@bytedance.com
> * [PATCH v1 01/26] mm: memcontrol: remove dead code of checking parent memory cgroup
> * [PATCH v1 02/26] mm: workingset: use folio_lruvec() in workingset_refault()
> * [PATCH v1 03/26] mm: rename unlock_page_lruvec_irq and its variants
> * [PATCH v1 04/26] mm: vmscan: refactor move_folios_to_lru()
> * [PATCH v1 05/26] mm: memcontrol: allocate object cgroup for non-kmem case
> * [PATCH v1 06/26] mm: memcontrol: return root object cgroup for root memory cgroup
> * [PATCH v1 07/26] mm: memcontrol: prevent memory cgroup release in get_mem_cgroup_from_folio()
> * [PATCH v1 08/26] buffer: prevent memory cgroup release in folio_alloc_buffers()
> * [PATCH v1 09/26] writeback: prevent memory cgroup release in writeback module
> * [PATCH v1 10/26] mm: memcontrol: prevent memory cgroup release in count_memcg_folio_events()
> * [PATCH v1 11/26] mm: page_io: prevent memory cgroup release in page_io module
> * [PATCH v1 12/26] mm: migrate: prevent memory cgroup release in folio_migrate_mapping()
> * [PATCH v1 13/26] mm: mglru: prevent memory cgroup release in mglru
> * [PATCH v1 14/26] mm: memcontrol: prevent memory cgroup release in mem_cgroup_swap_full()
> * [PATCH v1 15/26] mm: workingset: prevent memory cgroup release in lru_gen_eviction()
> * [PATCH v1 16/26] mm: thp: prevent memory cgroup release in folio_split_queue_lock{_irqsave}()
> * [PATCH v1 17/26] mm: workingset: prevent lruvec release in workingset_refault()
> * [PATCH v1 18/26] mm: zswap: prevent lruvec release in zswap_folio_swapin()
> * [PATCH v1 19/26] mm: swap: prevent lruvec release in swap module
> * [PATCH v1 20/26] mm: workingset: prevent lruvec release in workingset_activation()
> * [PATCH v1 21/26] mm: memcontrol: prepare for reparenting LRU pages for lruvec lock
> * [PATCH v1 22/26] mm: vmscan: prepare for reparenting traditional LRU folios
> * [PATCH v1 23/26] mm: vmscan: prepare for reparenting MGLRU folios
> * [PATCH v1 24/26] mm: memcontrol: refactor memcg_reparent_objcgs()
> * [PATCH v1 25/26] mm: memcontrol: eliminate the problem of dying memory cgroup for LRU folios
> * [PATCH v1 26/26] mm: lru: add VM_WARN_ON_ONCE_FOLIO to lru maintenance helpers
> 
> and found the following issue:
> WARNING in folio_memcg
> 
> Full report is available here:
> https://ci.syzbot.org/series/0d48a77a-fb4f-485d-9fd6-086afd6fb650
> 
> ***
> 
> WARNING in folio_memcg
> 
> tree:      mm-new
> URL:       https://kernel.googlesource.com/pub/scm/linux/kernel/git/akpm/mm.git
> base:      b227c04932039bccc21a0a89cd6df50fa57e4716
> arch:      amd64
> compiler:  Debian clang version 20.1.8 (++20250708063551+0c9f909b7976-1~exp1~20250708183702.136), Debian LLD 20.1.8
> config:    https://ci.syzbot.org/builds/503d7034-ae99-44d1-8fb2-62e7ef5e1c7c/config
> C repro:   https://ci.syzbot.org/findings/880c374a-1b49-436e-9be2-63d5e2c6b6ab/c_repro
> syz repro: https://ci.syzbot.org/findings/880c374a-1b49-436e-9be2-63d5e2c6b6ab/syz_repro
> 
> exFAT-fs (loop0): failed to load upcase table (idx : 0x00010000, chksum : 0xe5674ec2, utbl_chksum : 0xe619d30d)
> exFAT-fs (loop0): failed to load alloc-bitmap
> exFAT-fs (loop0): failed to recognize exfat type
> ------------[ cut here ]------------
> WARNING: CPU: 1 PID: 5965 at ./include/linux/memcontrol.h:380 obj_cgroup_memcg include/linux/memcontrol.h:380 [inline]
> WARNING: CPU: 1 PID: 5965 at ./include/linux/memcontrol.h:380 folio_memcg+0x148/0x1c0 include/linux/memcontrol.h:434

This is understandable as the code snippet was added fairly recently
and is easy to miss during rebasing.

#syz test

diff --git a/mm/zswap.c b/mm/zswap.c
index a341814468b9..738d914e5354 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -896,11 +896,14 @@ static bool zswap_compress(struct page *page, struct zswap_entry *entry,
 	 * to the active LRU list in the case.
 	 */
 	if (comp_ret || !dlen || dlen >= PAGE_SIZE) {
+		rcu_read_lock();
 		if (!mem_cgroup_zswap_writeback_enabled(
 					folio_memcg(page_folio(page)))) {
+			rcu_read_unlock();
 			comp_ret = comp_ret ? comp_ret : -EINVAL;
 			goto unlock;
 		}
+		rcu_read_unlock();
 		comp_ret = 0;
 		dlen = PAGE_SIZE;
 		dst = kmap_local_page(page);