linux-kernel - Re: [PATCH v3 00/30] Eliminate Dying Memory Cgroup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aWouRwBftqNDz10t@tiehlicka>
Date: Fri, 16 Jan 2026 13:25:43 +0100
From: Michal Hocko <mhocko@...e.com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
	Qi Zheng <qi.zheng@...ux.dev>, hannes@...xchg.org, hughd@...gle.com,
	roman.gushchin@...ux.dev, shakeel.butt@...ux.dev,
	muchun.song@...ux.dev, david@...nel.org, ziy@...dia.com,
	harry.yoo@...cle.com, yosry.ahmed@...ux.dev,
	imran.f.khan@...cle.com, kamalesh.babulal@...cle.com,
	axelrasmussen@...gle.com, yuanchu@...gle.com, weixugc@...gle.com,
	chenridong@...weicloud.com, mkoutny@...e.com,
	hamzamahfooz@...ux.microsoft.com, apais@...ux.microsoft.com,
	lance.yang@...ux.dev, linux-mm@...ck.org,
	linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
	Qi Zheng <zhengqi.arch@...edance.com>
Subject: Re: [PATCH v3 00/30] Eliminate Dying Memory Cgroup

On Fri 16-01-26 08:33:44, Lorenzo Stoakes wrote:
> On Thu, Jan 15, 2026 at 04:43:06PM -0800, Andrew Morton wrote:
> > On Thu, 15 Jan 2026 12:40:12 +0000 Lorenzo Stoakes <lorenzo.stoakes@...cle.com> wrote:
> >
> > > On Wed, Jan 14, 2026 at 09:58:39AM -0800, Andrew Morton wrote:
> > > > On Wed, 14 Jan 2026 19:26:43 +0800 Qi Zheng <qi.zheng@...ux.dev> wrote:
> > > >
> > > > > This patchset is intended to transfer the LRU pages to the object cgroup
> > > > > without holding a reference to the original memory cgroup in order to
> > > > > address the issue of the dying memory cgroup.
> > > >
> > > > Thanks.  I'll add this to mm.git for testing.  A patchset of this
> > > > magnitude at -rc5 is a little ambitious, but Linus is giving us an rc8
> > > > so let's see.
> > > >
> > > > I'll suppress the usual added-to-mm email spray.
> > >
> > > Since this is so large and we are late on in the cycle can I in this case
> > > can I explicitly ask for at least 1 sub-M tag on each commit before
> > > queueing for Linus please?
> >
> > Well, kinda.
> >
> > fs/buffer.c
> > fs/fs-writeback.c
> > include/linux/memcontrol.h
> > include/linux/mm_inline.h
> > include/linux/mmzone.h
> > include/linux/swap.h
> > include/trace/events/writeback.h
> > mm/compaction.c
> > mm/huge_memory.c
> > mm/memcontrol.c
> > mm/memcontrol-v1.c
> > mm/memcontrol-v1.h
> > mm/migrate.c
> > mm/mlock.c
> > mm/page_io.c
> > mm/percpu.c
> > mm/shrinker.c
> > mm/swap.c
> > mm/vmscan.c
> > mm/workingset.c
> > mm/zswap.c
> >
> > That's a lot of reviewers to round up!  And there are far worse cases -
> > MM patchsets are often splattered elsewhere.  We can't have MM
> > patchsets getting stalled because some video driver developer is on
> > leave or got laid off.  Not suggesting that you were really suggesting
> > that!
> 
> Yeah, obviously judgment needs to be applied in these situations - an 'M'
> implies community trusts sensible decisions, so since this is really about
> the cgroup behaviour, I'd say simply requiring at least 1 M per-patch from
> any of:
> 
> M:	Johannes Weiner <hannes@...xchg.org>
> M:	Michal Hocko <mhocko@...nel.org>
> M:	Roman Gushchin <roman.gushchin@...ux.dev>
> M:	Shakeel Butt <shakeel.butt@...ux.dev>
> 
> Suffices.

I have seen a good deal of review feedback from Johannes, Roman and
Shakeel (thx!). I have it on my todo list as well but the series is
really large and it is not that easy to find time to do the proper
review. Anyway, unlike before xmas when there was barely any review
and I asked to slow down I feel much more confident just by seeing acks
from others memcg maintainers.

That being said, if I fail to find proper time to review myself I am
fully confident to rely on other memcg maintainers here. So this should
not be blocked waiting for me.

Thanks!
-- 
Michal Hocko
SUSE Labs