From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1F6023803D1 for ; Thu, 26 Mar 2026 14:37:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774535862; cv=none; b=k79kcjL2jOOLa3DjzqTBzHA0CeTzxWgH3GRLMWzEKN7uR6bIDOr+jsbbrlcwcsplxgrLt8b2PrfKGCcYwA2mPRnUpelaiykWCseuh3ng48olut0SRJWRxLDY3T/kAhFSILcWnDccvEmjzFpCzDdUYnm+uHF5XqDQtE/nReR+pco= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774535862; c=relaxed/simple; bh=OmEcgOgtj9EB0U+r8Rz9OX3jwbG1LxV87ZIjPnC+RPo=; h=Date:From:To:Cc:Subject:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=dRGZcmhUbJc5+6wDRH+bogM5vvg7MXy88Bu8tSz2KLxiAFcuHOvMko6AH4Ts+T1/xyPunstPVMeHkoqEWojxx98KxbTAUIa3TlXGbQEluw6CgeGLEnBFSrifFN+rif8RfRshzDnBOCOyQdxN2rkjiDht23lBTVUNkakRdPfN40s= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=Q7oBd7Hr; arc=none smtp.client-ip=209.85.128.42 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="Q7oBd7Hr" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-48704db565eso14954465e9.1 for ; Thu, 26 Mar 2026 07:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774535859; x=1775140659; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=LExnV0j7gKvFxp2DijKwHbwyH1cYLP8Al1bnrSceMkk=; b=Q7oBd7HryExTeEZPtMEpHYy1jukbg2OaSzLvr6V0GvAW1mHmoAGT2YtG9EW2J+El8W BgqwNb/aUZHBgmjP68/DZosdLtB3doUjMUmQf9pFjtWFgnJ2X8DHEoCKO7ARzvw9mOkK UgwLYCyn5uQpeQwhBOMBPvEeBg2es13hCj/ipAw3Qu48rEqcWGkp+7DU9rH7JSxCmvfK 7mzf5qQtX3uo8McZfZ6fcVUEPYYksrsWKzyb7RidZzFBqJxcc8MQoEboj3ckisnaeNht p2yB0NC7Yd3Vwei5DhtNDe2ajY27BPoVly0Wb7uQfycO+LLqM51vYhUTbEhP1nNReb5n mL/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774535859; x=1775140659; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=LExnV0j7gKvFxp2DijKwHbwyH1cYLP8Al1bnrSceMkk=; b=nVH1cQJE5sQmammFQmekIbYbNAuUFg4ujJFJe0mQoh21uNHRScKJoZnhxiY1Ua7FxE mWCwcyTlCTSBFKZPGVs/BxmSrpPvNjROm7s0Ycl1YuTlB8vmmyJeRgu0O4ukBe0QmHdO qOuJbCjDET8P2Eam8/41Fq7nDvxZ3U38VUp4OjVDW0oRrDUH0bBFe+yeg/CWHZu2Sb7k MqTMcQNBByhL+BkTesIaPEJJr/UnxVOIphbyjA2JLMRM46x94O2ZOA9BpEpikzG9wpyr O8LZ5lLU9WxdJicql5Ma7Hl2bjhs4sIP2aAUpIKhXgonxUEHB2Vi/D33dG+Y5bbU/bXg KZvA== X-Forwarded-Encrypted: i=1; AJvYcCVJhgqCH2Bl/EZjzJjjD+syxG4Her1S9IRWDBbYOhurUtU5yoSaYZJ39KZYNDthbb98gkwvMLlT8apgJTs=@vger.kernel.org X-Gm-Message-State: AOJu0YzF1Hh5wQNonO9KLc8kspF8e21BPPcEL+Nglc14nhW72UUOkIvB iKK7fiu4170QzQZFM22e/IKlVu+gu7yLUdfbRmTpay6/j+kwv2o9NccP X-Gm-Gg: ATEYQzzLoA6uadv62FVQQDWjVHk7akN7XrBg4pgsK85hESojHL8OaqHOOCopRiOHlcw 9CMWQTFwemXpQMyo1rXTrKTOxRImEMyCXdRCldpUPEVWONBkf02owD5hlVl/zGi3jvOms05jLcc vE7SHICYSeqY9ONnMqr8U0NW67kkjKHaQXWl//fvgMZGJNB1Gc0WoJEpqKiS74GJrt/r+toxWBE TCemuMwExGGkOflQFIlJMiQaOtSEjjFaLOyRrHu5CFdVdEJPLlLCULPJahu7vu812dIttb7hDHv FK2hR7z8g3utFidlh9cy5SP3NgBGHUPaRiyOMWWlKI+6L3R7xSoTZMt4IbPh6H/FWPaYHUb0SGe 7srkVryv/69rcaw3eIilH+MjW1NR01wIrzgYFiXW2lwTGg6yKNp9tFBdY9DCA6ZomjSAXxWpsHX pZhS/k4bMuZvt+K1gGrMKFzu6E0DAsHYmRU2P4z0TO8L4+Ot/ivnigwWUYLTUA9ARo X-Received: by 2002:a05:600c:4685:b0:485:2ce2:4c87 with SMTP id 5b1f17b1804b1-48715fc3562mr126363235e9.4.1774535858924; Thu, 26 Mar 2026 07:37:38 -0700 (PDT) Received: from pumpkin (82-69-66-36.dsl.in-addr.zen.co.uk. [82.69.66.36]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4871fbbf65asm24277075e9.2.2026.03.26.07.37.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 26 Mar 2026 07:37:38 -0700 (PDT) Date: Thu, 26 Mar 2026 14:37:36 +0000 From: David Laight To: "Lorenzo Stoakes (Oracle)" Cc: Qi Zheng , hannes@cmpxchg.org, hughd@google.com, mhocko@suse.com, roman.gushchin@linux.dev, shakeel.butt@linux.dev, muchun.song@linux.dev, david@kernel.org, ziy@nvidia.com, harry.yoo@oracle.com, yosry.ahmed@linux.dev, imran.f.khan@oracle.com, kamalesh.babulal@oracle.com, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, chenridong@huaweicloud.com, mkoutny@suse.com, akpm@linux-foundation.org, hamzamahfooz@linux.microsoft.com, apais@linux.microsoft.com, lance.yang@linux.dev, bhe@redhat.com, usamaarif642@gmail.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qi Zheng Subject: Re: [PATCH v2 2/4] mm: memcontrol: change val type to long in __mod_memcg_{lruvec_}state() Message-ID: <20260326143736.12d22e38@pumpkin> In-Reply-To: References: <5c42058df0e52a4698da005e502deb2fae7bf819.1774447069.git.zhengqi.arch@bytedance.com> X-Mailer: Claws Mail 4.1.1 (GTK 3.24.38; arm-unknown-linux-gnueabihf) 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=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 26 Mar 2026 09:19:29 +0000 "Lorenzo Stoakes (Oracle)" wrote: > On Wed, Mar 25, 2026 at 10:13:23PM +0800, Qi Zheng wrote: > > From: Qi Zheng > > > > The __mod_memcg_state() and __mod_memcg_lruvec_state() functions are also > > used to reparent non-hierarchical stats. In this scenario, the values > > passed to them are accumulated statistics that might be extremely large > > and exceed the upper limit of a 32-bit integer. > > > > Change the val parameter type from int to long in these functions and > > their corresponding tracepoints (memcg_rstat_stats) to prevent potential > > overflow issues. Won't that are be true on 32bit systems? Which means the underlying values need to be u64 not long. David > > > > Signed-off-by: Qi Zheng > > LGTM, so: > > Reviewed-by: Lorenzo Stoakes (Oracle) > > > --- > > include/trace/events/memcg.h | 10 +++++----- > > mm/memcontrol.c | 8 ++++---- > > 2 files changed, 9 insertions(+), 9 deletions(-) > > > > diff --git a/include/trace/events/memcg.h b/include/trace/events/memcg.h > > index dfe2f51019b4c..51b62c5931fc2 100644 > > --- a/include/trace/events/memcg.h > > +++ b/include/trace/events/memcg.h > > @@ -11,14 +11,14 @@ > > > > DECLARE_EVENT_CLASS(memcg_rstat_stats, > > > > - TP_PROTO(struct mem_cgroup *memcg, int item, int val), > > + TP_PROTO(struct mem_cgroup *memcg, int item, long val), > > > > TP_ARGS(memcg, item, val), > > > > TP_STRUCT__entry( > > __field(u64, id) > > __field(int, item) > > - __field(int, val) > > + __field(long, val) > > ), > > > > TP_fast_assign( > > @@ -27,20 +27,20 @@ DECLARE_EVENT_CLASS(memcg_rstat_stats, > > __entry->val = val; > > ), > > > > - TP_printk("memcg_id=%llu item=%d val=%d", > > + TP_printk("memcg_id=%llu item=%d val=%ld", > > __entry->id, __entry->item, __entry->val) > > ); > > > > DEFINE_EVENT(memcg_rstat_stats, mod_memcg_state, > > > > - TP_PROTO(struct mem_cgroup *memcg, int item, int val), > > + TP_PROTO(struct mem_cgroup *memcg, int item, long val), > > > > TP_ARGS(memcg, item, val) > > ); > > > > DEFINE_EVENT(memcg_rstat_stats, mod_memcg_lruvec_state, > > > > - TP_PROTO(struct mem_cgroup *memcg, int item, int val), > > + TP_PROTO(struct mem_cgroup *memcg, int item, long val), > > > > TP_ARGS(memcg, item, val) > > ); > > diff --git a/mm/memcontrol.c b/mm/memcontrol.c > > index 7fb9cbc10dfbb..4a78550f6174e 100644 > > --- a/mm/memcontrol.c > > +++ b/mm/memcontrol.c > > @@ -527,7 +527,7 @@ unsigned long lruvec_page_state_local(struct lruvec *lruvec, > > > > #ifdef CONFIG_MEMCG_V1 > > static void __mod_memcg_lruvec_state(struct mem_cgroup_per_node *pn, > > - enum node_stat_item idx, int val); > > + enum node_stat_item idx, long val); > > > > void reparent_memcg_lruvec_state_local(struct mem_cgroup *memcg, > > struct mem_cgroup *parent, int idx) > > @@ -784,7 +784,7 @@ static int memcg_page_state_unit(int item); > > * Normalize the value passed into memcg_rstat_updated() to be in pages. Round > > * up non-zero sub-page updates to 1 page as zero page updates are ignored. > > */ > > -static int memcg_state_val_in_pages(int idx, int val) > > +static long memcg_state_val_in_pages(int idx, long val) > > { > > int unit = memcg_page_state_unit(idx); > > > > @@ -831,7 +831,7 @@ static inline void get_non_dying_memcg_end(void) > > #endif > > > > static void __mod_memcg_state(struct mem_cgroup *memcg, > > - enum memcg_stat_item idx, int val) > > + enum memcg_stat_item idx, long val) > > { > > int i = memcg_stats_index(idx); > > int cpu; > > @@ -896,7 +896,7 @@ void reparent_memcg_state_local(struct mem_cgroup *memcg, > > #endif > > > > static void __mod_memcg_lruvec_state(struct mem_cgroup_per_node *pn, > > - enum node_stat_item idx, int val) > > + enum node_stat_item idx, long val) > > { > > struct mem_cgroup *memcg = pn->memcg; > > int i = memcg_stats_index(idx); > > -- > > 2.20.1 > > >