From nobody Tue Sep 29 06:59:42 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A47C3427A03 for ; Tue, 11 Aug 2026 09:41:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441266; cv=none; b=qWiuvdigIz4jovfHTN2Nz0ax5g3uRkGrmRTeqZ7j0O69xkjW+mdzv2ggHVSDHqWxZXui8tEBe6YWXl4H7o0mF7CAjhVz24RzDH/Nk2+1KTx7PbOXIMFUHgyisLvg/GYR0Oy0Ovzwec7/HlBvYvd+iZcS+QJaloiyRUjGUTZkKEU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786441266; c=relaxed/simple; bh=upF6x0o7MEfxdunfBPIzs8sc5yUg/F5ysQ6zU4l78Qg=; h=From:Date:Subject:MIME-Version:Content-Type:Message-Id:To:Cc; b=IyHL8Q8eCH88E0il++fK8FlyYZRcpw8/wRaMd+uVckqVWPTAk42kOzt6ZtEPaPpgHnvsdljO/tRxslaK5Ro+fMN65hTnK1XmEvYXbD7HWAj44djO+VS0+kwQu82rNpjxhVJxhn0n24M904Kd4swB31wgVbdQGXCBYQKW1CdCgLs= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=tUQnA5D9; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="tUQnA5D9" Received: by smtp.kernel.org (Postfix) with ESMTPS id 1F5E6C2BCF6; Tue, 11 Aug 2026 09:41:06 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1786441266; bh=upF6x0o7MEfxdunfBPIzs8sc5yUg/F5ysQ6zU4l78Qg=; h=From:Date:Subject:To:Cc:Reply-To:From; b=tUQnA5D9IZIc+qWfRvafUjrKqa7i8C4onzAbmmHdXBZHGQlt6mxmO6q1eJswgBhST X4WJtxFJQCqC4GhWQyoeGuBZSbr7qP35D/elS3dHMphliFdZKShlSOWVzH3kHqM5+H lBe3iSyXH/JAE3HQ2lvZs7xhQAtvM8vafhvCbVj5VkKnoKNtT1e+XwGd09GhiMpbSb WOOWkFDcDO18UL71Yij2ZNdWP1zFmGsVpi2Z51EPrhL2goqiAolVuXD52JuLiB34WE X8KKB/wUXqpXr6ZhX3XOFmOq7wiNA2+WrvV3ps20MQdBqyBhu7S/dQHsj1YSaIqGPH c6J3yoU2VQrFg== Received: from aws-us-west-2-korg-lkml-1.web.codeaurora.org (localhost.localdomain [127.0.0.1]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0B97FC5CFCF; Tue, 11 Aug 2026 09:41:06 +0000 (UTC) From: Kairui Song via B4 Relay Date: Tue, 11 Aug 2026 17:40:59 +0800 Subject: [PATCH] mm/mglru: fix and remove redundant unevictable folio handling Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <20260811-mglru-mlock-fix-v1-1-8b2321d0e1d3@tencent.com> X-B4-Tracking: v=1; b=H4sIAAAAAAAC/yXMyw5AMBCF4VeRWZukbYTGq4gF7WDc0yIS8e6K5 XeS81/gyTF5yKMLHB3seZkDZByB6aq5JWQbDEqoVGgpcWpHt+M0LmbAhk9UwupG20QnWQXhtTo K81csyt9+r3sy25uB+34AG5uiK3MAAAA= X-Change-ID: 20260811-mglru-mlock-fix-20d8f8d4847a To: linux-mm@kvack.org Cc: Andrew Morton , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Oleksandr Natalenko , Suleiman Souhlal , "Jan Alexander Steffens (heftig)" , Yu Zhao , Steven Barrett , Brian Geffon , Kairui Song , linux-kernel@vger.kernel.org, Kairui Song X-Mailer: b4 0.16.0 X-Developer-Signature: v=1; a=ed25519-sha256; t=1786441264; l=3658; i=kasong@tencent.com; s=kasong-sign-tencent; h=from:subject:message-id; bh=aS+xGS5ivQ4MJAkh8ZjAYFluAUdKiZoNB6Hp2uOPFCA=; b=QzDpMiOdqiQmyPPYubWEQCxOqQVgNxoWgUQfC69RFxUpR41Fgir6Rm9fCjFwnrwJG6Xy3ZmuS jd7TJKAvYZWAmDOYhA08FgQYA3LEd5Bkud5u8gVcVBeRXKmO1bJ+qH4 X-Developer-Key: i=kasong@tencent.com; a=ed25519; pk=kCdoBuwrYph+KrkJnrr7Sm1pwwhGDdZKcKrqiK8Y1mI= X-Endpoint-Received: by B4 Relay for kasong@tencent.com/kasong-sign-tencent with auth_id=562 X-Original-From: Kairui Song Reply-To: kasong@tencent.com From: Kairui Song sort_folio() has a shortcut for moving folios that are no longer evictable but are still sitting on a generation list. However, this shortcut is buggy. It does not follow the PG_lru usage convention, and it has a more serious issue. Unevictable folios are not threaded on lists[LRU_UNEVICTABLE], so that folio->lru can be reused to hold folio->mlock_count (see the comment in lruvec_init()). Hence lruvec_add_folio() skips the list_add() for them, and every other place that turns a folio unevictable initialises mlock_count explicitly: lru_add() sets it to 0, __mlock_folio() and __mlock_new_folio() set it to !!folio_test_mlocked(folio). sort_folio() sets nothing, and the lru_gen_del_folio() right above it may have already poisoned folio->lru via list_del(), so mlock_count ends up aliasing LIST_POISON2, which reads as 0x122, i.e. 290. The result is user visible. On munlock, __munlock_folio() decrements that bogus count, finds it still non-zero and bails out before clearing PG_mlocked, so the folio remains unevictable and the Mlocked accounting stays inflated until the folio is freed. The shortcut also touches the LRU flags in the wrong order. It calls lru_gen_del_folio() while PG_lru is still set, so a concurrent folio_test_clear_lru() (e.g. compaction, folio_isolate_lru()) can succeed on a folio that has already been taken off the generation list, may lead to unexpected behavior. The generic path gets this right: isolate_folio() clears PG_lru first, so a racing isolator loses the atomic and bails. And the shortcut is redundant. A folio left on the generation list is picked up by isolate_folio(), shrink_folio_list() sends it to activate_locked on the !folio_evictable() check, and evict_folios() then hands it to folio_putback_lru(), which sets PG_unevictable and counts UNEVICTABLE_PGCULLED from lru_add(), with mlock_count initialised properly. There is no performance concern either: such a folio goes through this once, and then it is off the generation lists for good, since lru_gen_add_folio() refuses unevictable folios. So just remove the shortcut. This consolidates unevictable handling in the generic path, and makes maintenance easier. Fixes: ac35a4902374 ("mm: multi-gen LRU: minimal implementation") Signed-off-by: Kairui Song Reviewed-by: Baolin Wang --- mm/vmscan.c | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 3194da7dcc79..eca5ff64238d 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4648,7 +4648,6 @@ void lru_gen_reparent_memcg(struct mem_cgroup *memcg,= struct mem_cgroup *parent, static bool sort_folio(struct lruvec *lruvec, struct folio *folio, struct = scan_control *sc, int tier_idx) { - bool success; int gen =3D folio_lru_gen(folio); int type =3D folio_is_file_lru(folio); int zone =3D folio_zonenum(folio); @@ -4660,16 +4659,6 @@ static bool sort_folio(struct lruvec *lruvec, struct= folio *folio, struct scan_c =20 VM_WARN_ON_ONCE_FOLIO(gen >=3D MAX_NR_GENS, folio); =20 - /* unevictable */ - if (!folio_evictable(folio)) { - success =3D lru_gen_del_folio(lruvec, folio, true); - VM_WARN_ON_ONCE_FOLIO(!success, folio); - folio_set_unevictable(folio); - lruvec_add_folio(lruvec, folio); - __count_vm_events(UNEVICTABLE_PGCULLED, delta); - return true; - } - /* promoted */ if (gen !=3D lru_gen_from_seq(lrugen->min_seq[type])) { list_move(&folio->lru, &lrugen->folios[gen][type][zone]); --- base-commit: 1029098ee3275ea5b78e329ce132262affa2f8cc change-id: 20260811-mglru-mlock-fix-20d8f8d4847a Best regards, -- =20 Kairui Song