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: <20260115164306.58a9a010de812e7ac649d952@linux-foundation.org>
Date: Thu, 15 Jan 2026 16:43:06 -0800
From: Andrew Morton <akpm@...ux-foundation.org>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Qi Zheng <qi.zheng@...ux.dev>, hannes@...xchg.org, hughd@...gle.com,
 mhocko@...e.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 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!

As this is officially a memcg patch, I'd be looking to memcg
maintainers for guidance while viewing acks from others as
nice-to-have, rather than must-have.

> We are seeing kernel bot reports here so let's obviously stabilise this for
> a while also.

Yeah, I'm not feeling optimistic about getting all this into the next
merge window.  But just one day in mm-new led to David's secret ci-bot
discovering a missed rcu_unlock due to a cross-tree integration thing.

I'll keep the series around for at least a few days, see how things
progress.