From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 CEC77381B0D for ; Tue, 24 Mar 2026 14:12:14 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774361536; cv=none; b=PY/soB5TUyEGugUHDwrtlIYAjzSJ3qStf84Z+BFS3Db4a6+pr2e9YfcdDo5bYi92EkuVHZWeFUWx8DazyaeAvFKegbuZVN7EYd3tuKmRKvgAVEP2+CbretQkR9mqu8X/CFw0gjxdY4/r7XLn43YmpivoBIYeOUdMIHK1bE6EGKo= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774361536; c=relaxed/simple; bh=bh05csAAbNOiWVD/VM8WEa27ehf/0DOkR0bMEdDjMaQ=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=nmpJSH80dF4R64umxg2FWqWUrj14N//aZWDrPjGGf9Ue2+TagZfZRzLhzATZv9ibRLgUCamqI6Ui1/cF9y1ChX2nOzTSBcMxp9nShhjUOtzQW8LYnQzDq6uuQ8/C7SOIiwGAvuVA/CvpV7t1lZZWefR1tZZKKDBkpwYj8sj8yQc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=kIQoAm2j; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="kIQoAm2j" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=RKNKZO1PbDIycc63ngbj8ytXMIyj96P0J6kd55apnPc=; b=kIQoAm2jaL+V9pTcaMnaKYeDuJ bGm1wxYkTbQEUfD7aggvjhnMlMDdM66UO6ERcgyRtV8494+Au6FVCzvNp1XHW8K7Bs+a/qXwMhHTb fQVS3CsgcD5v/ura4Wm7HoCpvOTtJS8hfjNw3+tYLb4kIP6RLi/6GtpBuPkG2DW9XmjuK09DTsonN tRvEk0VvGxZbs2vMsb/qfUzjy0gDU/r4hLFXUtA2Sh0yZFbjcJLAgRVwLIq6mZ8SmNCrrBGx7HSt4 gA/6jgfjHqAYSKRBE5pO8uUvdc//7sGBCe9GoEYdKeh3hDn8mNGdnE4kqK8vhge+RivgnjE7QYg9W L6sBl7og==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1w52UC-0000000E8K6-16qW; Tue, 24 Mar 2026 14:12:00 +0000 Date: Tue, 24 Mar 2026 14:12:00 +0000 From: Matthew Wilcox 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, lorenzo.stoakes@oracle.com, 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 2/3] mm: memcontrol: correct the parameter type of __mod_memcg{_lruvec}_state() Message-ID: References: <90524ca3806e24105ab5f2d69435f57c2ae034cb.1774342371.git.zhengqi.arch@bytedance.com> <98dfab09-f3c5-4503-94e4-c3f097539afd@lucifer.local> 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-Disposition: inline In-Reply-To: <98dfab09-f3c5-4503-94e4-c3f097539afd@lucifer.local> On Tue, Mar 24, 2026 at 12:21:06PM +0000, Lorenzo Stoakes (Oracle) wrote: > On Tue, Mar 24, 2026 at 07:31:28PM +0800, Qi Zheng wrote: > > From: Qi Zheng > > > > The __mod_memcg_state() and __mod_memcg_lruvec_state() were used to > > reparent non-hierarchical stats, the values passed to them might exceed > > the upper limit of the type int, so correct the val parameter type of them > > Why might they? What precipitated this change? > > > to long. > > Why is it a signed value? Because 'mod' can both increase and decrease this counter. It must be signed.