netdev - Re: [PATCH v1 net-next 13/13] net-memcg: Allow decoupling memcg from global protocol memory accounting.

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] [day] [month] [year] [list]

Message-ID: <CAAVpQUD36Wq7xcmdpeqCb3qpTzR7ZUDa=U4rUrfy7+JiE47Rsg@mail.gmail.com>
Date: Fri, 25 Jul 2025 11:50:57 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Shakeel Butt <shakeel.butt@...ux.dev>, Eric Dumazet <edumazet@...gle.com>, 
	Michal Koutný <mkoutny@...e.com>, Tejun Heo <tj@...nel.org>, 
	"David S. Miller" <davem@...emloft.net>, Neal Cardwell <ncardwell@...gle.com>, 
	Paolo Abeni <pabeni@...hat.com>, Willem de Bruijn <willemb@...gle.com>, 
	Matthieu Baerts <matttbe@...nel.org>, Mat Martineau <martineau@...nel.org>, 
	Johannes Weiner <hannes@...xchg.org>, Michal Hocko <mhocko@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, Andrew Morton <akpm@...ux-foundation.org>, 
	Simon Horman <horms@...nel.org>, Geliang Tang <geliang@...nel.org>, 
	Muchun Song <muchun.song@...ux.dev>, Kuniyuki Iwashima <kuni1840@...il.com>, netdev@...r.kernel.org, 
	mptcp@...ts.linux.dev, cgroups@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v1 net-next 13/13] net-memcg: Allow decoupling memcg from
 global protocol memory accounting.

On Thu, Jul 24, 2025 at 6:49 PM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 23 Jul 2025 11:06:14 -0700 Kuniyuki Iwashima wrote:
> > > 3. Will there ever be a reasonable use-case where there is non-isolated
> > >    sub-tree under an isolated ancestor?
> >
> > I think no, but again, we need to think about the scenario above,
> > otherwise, your ideal semantics is just broken.
> >
> > Also, "no reasonable scenario" does not always mean "we must
> > prevent the scenario".
> >
> > If there's nothing harmful, we can just let it be, especially if such
> > restriction gives nothing andrather hurts performance with no
> > good reason.
>
> Stating the obvious perhaps but it's probably too late in the release
> cycle to get enough agreement here to merge the series. So I'll mark
> it as Deferred.

Fair enough.

>
> While I'm typing, TBH I'm not sure I'm following the arguments about
> making the property hierarchical. Since the memory limit gets inherited
> I don't understand why the property of being isolated would not.
> Either I don't understand the memcg enough, or I don't understand your
> intended semantics. Anyway..

Inheriting a config is easy, but keeping the hierarchy complete isn't,
or maybe I'm thinking too hard :S

[root@...ora ~]# mkdir /sys/fs/cgroup/test1
[root@...ora ~]# mkdir /sys/fs/cgroup/test1/test2
[root@...ora ~]# echo +memory > /sys/fs/cgroup/test1/cgroup.subtree_control
[root@...ora ~]# echo 10000 > /sys/fs/cgroup/test1/test2/memory.max
[root@...ora ~]# echo 1000 > /sys/fs/cgroup/test1/memory.max
[  108.130895] bash invoked oom-killer: gfp_mask=0xcc0(GFP_KERNEL),
order=0, oom_score_adj=0
...
[  108.260164] Out of memory and no killable processes...
[root@...ora ~]# cat /sys/fs/cgroup/test1/test2/memory.max
8192
[root@...ora ~]# cat /sys/fs/cgroup/test1/memory.max
0