From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 7F24627472 for ; Fri, 27 Mar 2026 00:06:24 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774569984; cv=none; b=c9Gqc4Owk7qn6BkvRu2jW22fRF4gNkCZVyeo3pkdYX70AaXI5OBSvQfTohjM/PJHU/+ZDfOPXAW2WVKzUWYaNmxrafE6MgSrZE2YQ4SYlbfTn21oyOwMNSdgZvAFR4CKiJCQvcp7aBxewvVQvMGxZMudCcRALwx4rRNrPoO9JjI= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774569984; c=relaxed/simple; bh=tIxWNPioZeB760ZIilD4JasNvCWBjRA1vJaudNGQ+S0=; h=Date:From:To:Cc:Subject:Message-Id:In-Reply-To:References: Mime-Version:Content-Type; b=DHPdQS7TPeLI3ri4MxWddhacvlL+zpmocAua8UCCSUpgy4V4FYcgJPIEpuUYo09PThF7vLvyO8F/kxZ9Tf1z73OSX1zH5kljUoQLPzMY1gM49mGwix49n6CQUnARQTNfIYhvAqGZ5+FPQwJX7DEVJJFqAYfCfASb0zNmahJx+OY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=PIy4P2AJ; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="PIy4P2AJ" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3EDF5C116C6; Fri, 27 Mar 2026 00:06:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1774569984; bh=tIxWNPioZeB760ZIilD4JasNvCWBjRA1vJaudNGQ+S0=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=PIy4P2AJu++CYLAq0ZDAIEG8EJTijbqNcHNipK3qJF+zxgq4tLVPFy1KJvwqzorG6 wifP52LJQ4mCuEjhklG8qCg7Nh0jlRV5I4YasqXiFmQH8FuIiA4R+HrWrRRRMcnXva vyVFx71zBtRdlJxjoP5Bm9r9qYz4nL2Q1dqAJOd0= Date: Thu, 26 Mar 2026 17:06:22 -0700 From: Andrew Morton 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, 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 Subject: Re: [PATCH v2 4/4] mm: memcontrol: fix unexpected massive positive number in memcg_state_val_in_pages() Message-Id: <20260326170622.8fa7ca34d1425c241525bd41@linux-foundation.org> In-Reply-To: <9ee51ac2-c87c-44f6-b983-44ac9007cb35@lucifer.local> References: <54c2b09c-84f8-4118-96a6-acc13ca2f245@lucifer.local> <9ee51ac2-c87c-44f6-b983-44ac9007cb35@lucifer.local> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) 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: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 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). 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.