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: <fee37e75-e818-46b0-8494-684ef3eb5cd4@lucifer.local>
Date: Fri, 16 Jan 2026 08:33:44 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
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, 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 am obviously not suggesting that we require sign off from _all_ sub-M's
for _all_ affected files, and then some changes may be blurry.

For the most part I think it's usually _fairly_ obvious which part of
MAINTAINERS applies, and in cases where it doesn't obviously people can be
pinged for opinions.

>
> 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.

Yeah agreed.

>
> > 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.

Yeah and that's not a big deal, things can wait a little while esp. the
bigger changes!

Stabilising it is more important :)

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

Sounds sensible!

Cheers, Lorenzo