From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-174.mta0.migadu.com (out-174.mta0.migadu.com [91.218.175.174]) (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 940B42C21C2 for ; Fri, 27 Mar 2026 02:43:07 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774579390; cv=none; b=B8dHRcmrB0H0LY5oLQhqEaKQ151H0FBBEaweE72AGk4cp8o/+G5YjHoTNqEtO7XIxJEHQCAnP/bbBd0ro/JD35PVfUaTyGYOQYH/BHVgrf2NyZedHYy80SRU8lTyIEqwDyVL/A7WaGjCiW6O+VrJbH44VT+BNUioy3+IlFPMl+Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774579390; c=relaxed/simple; bh=ZETLLWicBQ5XEzHNjvslEUX3U/PWKCP57HAq8TWCNS0=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=kxevFe7xRYok3Yv+KQGgtdhGiNpSRNWlr661jRbPZbISfeBnJwrn1ffM9y1/5xcc24G2Wbama/BGBzNxyXicfzU1RomY2oOqF+BJmx2LRsISgDVJ0n8IT9unG0aCChXQcxrOrYv/elgoZvjQjJY7H2hyFJYjInidS+x6UBLmpc4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=ptL4Ik+K; arc=none smtp.client-ip=91.218.175.174 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="ptL4Ik+K" Message-ID: <0cf08b3f-6fed-41c4-8728-c925e8a55f29@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1774579385; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xjJ66u8oHnnbIM3Y1792Vd9Y/++lXVLGo/e8j2zXnT4=; b=ptL4Ik+KebH+WA8Qn4tD0wdWMGwkND0pb/0QxMeIqWlT2PSB1stK0uZgtU6z7Csslty0So nRvvBoUHwHXC7dpz0xfswuAABFuPzIHbTjeSS5xXcly4P2pd6jQSwzF2CR1K4O+5DKs7Oh iX+A7SzREiXy/PPsoFm2qqBCWtKg4+U= Date: Fri, 27 Mar 2026 10:42:52 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH v2 4/4] mm: memcontrol: fix unexpected massive positive number in memcg_state_val_in_pages() To: Andrew Morton , "Lorenzo Stoakes (Oracle)" Cc: 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, 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, "Harry Yoo (Oracle)" , Qi Zheng References: <54c2b09c-84f8-4118-96a6-acc13ca2f245@lucifer.local> <9ee51ac2-c87c-44f6-b983-44ac9007cb35@lucifer.local> <20260326170622.8fa7ca34d1425c241525bd41@linux-foundation.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Qi Zheng In-Reply-To: <20260326170622.8fa7ca34d1425c241525bd41@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 3/27/26 8:06 AM, Andrew Morton wrote: > On Thu, 26 Mar 2026 09:38:02 +0000 "Lorenzo Stoakes (Oracle)" wrote: > >>> >>> If Andrew needs me to merge this patchset into "[PATCH v6 00/33] Eliminate >>> Dying Memory Cgroup" [1], then I will develop and send v7. >>> >>> [1]. >>> https://lore.kernel.org/all/cover.1772711148.git.zhengqi.arch@bytedance.com/ >> >> Oh that's your series too :) >> >> That would be ideal unless that's already in mm-stable, as the series ordering >> will give us strict ordering on patches. >> >> Anyway let's wait for Andrew on that! > > > > Gee, I'd rather not churn that 33 patch series. Could of course do so Agree. > in the normal fashion, if that's considered particularly desirable. > > As I understand it, Qi will be preparing a v3 and I should stage that > ahead of "Eliminate ..." to avoid a bisection hole? > > If so, that works. > > > > Well dang, this series ("fix unexpected type conversions and potential > overflows") is at least textually dependent on "Eliminate ...". > > Options: > > a) Redo this "fix unexpected ..." series on top of "Eliminate ..." > and tolerate the bisection hole (easiest). From my personal perspective, I prefer this approach. The issues fixed by this patchset aren't too critical; it's just that the counter might overflow (and only with CONFIG_MEMCG_V1). If it can be included in v7.1-rcX along with "Eliminate ...", I think it's acceptable. Thanks, Qi > > Am I correct in believing that the concern here is a runtime > bisection hole? And that the bug is pretty unlikely to hit even if > our unlucky bisector happens to hit that hole? If so, we can live > with that, surely. Every darn hotfix we do creates a runtime > bisecton hole! > > b) Redo this series on top of mm-stable or mainline or whatever then > I stage this series ahead of "Eliminate ..." and fix up the merge > issues (probably OK) > > c) Qi redoes everything as a single series. That's OK. > > If we choose c) then please lmk and I'll drop both series to give Qi a > clean run at mm-unstable. >