[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20210527062148.9361-2-songmuchun@bytedance.com>
Date: Thu, 27 May 2021 14:21:28 +0800
From: Muchun Song <songmuchun@...edance.com>
To: willy@...radead.org, akpm@...ux-foundation.org, hannes@...xchg.org,
mhocko@...nel.org, vdavydov.dev@...il.com, shakeelb@...gle.com,
guro@...com, shy828301@...il.com, alexs@...nel.org,
richard.weiyang@...il.com, david@...morbit.com,
trond.myklebust@...merspace.com, anna.schumaker@...app.com
Cc: linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-mm@...ck.org, linux-nfs@...r.kernel.org,
zhengqi.arch@...edance.com, duanxiongchun@...edance.com,
fam.zheng@...edance.com, Muchun Song <songmuchun@...edance.com>
Subject: [PATCH v2 01/21] mm: list_lru: fix list_lru_count_one() return value
Since commit 2788cf0c401c ("memcg: reparent list_lrus and free kmemcg_id
on css offline"), the ->nr_items can be negative during memory cgroup
reparenting. In this case, list_lru_count_one() returns an unusual and
huge value. It can surprise users. So let it return zero when ->nr_items
is negative.
Signed-off-by: Muchun Song <songmuchun@...edance.com>
---
mm/list_lru.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/list_lru.c b/mm/list_lru.c
index cd58790d0fb3..4962d48d4410 100644
--- a/mm/list_lru.c
+++ b/mm/list_lru.c
@@ -176,13 +176,16 @@ unsigned long list_lru_count_one(struct list_lru *lru,
{
struct list_lru_node *nlru = &lru->node[nid];
struct list_lru_one *l;
- unsigned long count;
+ long count;
rcu_read_lock();
l = list_lru_from_memcg_idx(nlru, memcg_cache_id(memcg));
count = READ_ONCE(l->nr_items);
rcu_read_unlock();
+ if (unlikely(count < 0))
+ count = 0;
+
return count;
}
EXPORT_SYMBOL_GPL(list_lru_count_one);
--
2.11.0
Powered by blists - more mailing lists