linux-kernel - [PATCH] mm/list_lru: fix false warning of negative counter

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20241223150907.1591-1-ryncsn@gmail.com>
Date: Mon, 23 Dec 2024 23:09:07 +0800
From: Kairui Song <ryncsn@...il.com>
To: linux-mm@...ck.org
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Matthew Wilcox <willy@...radead.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Roman Gushchin <roman.gushchin@...ux.dev>,
	Shakeel Butt <shakeel.butt@...ux.dev>,
	Michal Hocko <mhocko@...e.com>,
	Chengming Zhou <zhouchengming@...edance.com>,
	Qi Zheng <zhengqi.arch@...edance.com>,
	Muchun Song <muchun.song@...ux.dev>,
	Yu Zhao <yuzhao@...gle.com>,
	Sasha Levin <sashal@...nel.org>,
	linux-kernel@...r.kernel.org,
	Kairui Song <kasong@...cent.com>
Subject: [PATCH] mm/list_lru: fix false warning of negative counter

From: Kairui Song <kasong@...cent.com>

commit 2788cf0c401c ("memcg: reparent list_lrus and free kmemcg_id
on css offline") removed sanity checks for the nr_items counter's value
because it implemented list_lru re-parenting in a way that will redirect
children's list_lru to the parent before re-parenting the items in
list_lru. This will make item counter uncharging happen in the parent
while the item is still being held by the child. As a result, the
parent's counter value may become negative. This is acceptable because
re-parenting will sum up the children's counter values, and the
parent's counter will be fixed.

Later commit fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup
scope") reworked the re-parenting process, and removed the redirect.
So it added the sanity check back, assuming that as long as items
are still in the children's list_lru, parent's counter will not be
uncharged.

But that assumption is incorrect. The xas_store
in memcg_reparent_list_lrus will set children's list_lru to NULL
before re-parenting the items, it redirects list_lru helpers to
use parent's list_lru just like before. But still, it's not a
problem as re-parenting will fix the counter.

Therefore, remove this sanity check, but add a new check to ensure
that the counter won't go negative in a different way: the child's
list_lru being re-parented should never have a negative counter,
since re-parenting should occur in order and fixes counters.

Fixes: fb56fdf8b9a2 ("mm/list_lru: split the lock to per-cgroup scope")
Closes: https://lore.kernel.org/lkml/Z2Bz9t92Be9l1xqj@lappy/
Signed-off-by: Kairui Song <kasong@...cent.com>
---
 mm/list_lru.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/list_lru.c b/mm/list_lru.c
index f93ada6a207b..7d69434c70e0 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -77,7 +77,6 @@ lock_list_lru_of_memcg(struct list_lru *lru, int nid, struct mem_cgroup *memcg,
 			spin_lock(&l->lock);
 		nr_items = READ_ONCE(l->nr_items);
 		if (likely(nr_items != LONG_MIN)) {
-			WARN_ON(nr_items < 0);
 			rcu_read_unlock();
 			return l;
 		}
@@ -450,6 +449,7 @@ static void memcg_reparent_list_lru_one(struct list_lru *lru, int nid,

 	list_splice_init(&src->list, &dst->list);
 	if (src->nr_items) {
+		WARN_ON(src->nr_items < 0);
 		dst->nr_items += src->nr_items;
 		set_shrinker_bit(dst_memcg, nid, lru_shrinker_id(lru));
 	}
-- 
2.47.1