netdev - Re: [PATCH v5 bpf-next/net 4/5] 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: <CAAVpQUDjNfU-fqhh4nfPPo1kg0LPcBRbU3ob22k8WtPU_BouZw@mail.gmail.com>
Date: Fri, 5 Sep 2025 14:56:36 -0700
From: Kuniyuki Iwashima <kuniyu@...gle.com>
To: Shakeel Butt <shakeel.butt@...ux.dev>
Cc: Johannes Weiner <hannes@...xchg.org>, Alexei Starovoitov <ast@...nel.org>, 
	Andrii Nakryiko <andrii@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Martin KaFai Lau <martin.lau@...ux.dev>, John Fastabend <john.fastabend@...il.com>, 
	Stanislav Fomichev <sdf@...ichev.me>, Michal Hocko <mhocko@...nel.org>, 
	Roman Gushchin <roman.gushchin@...ux.dev>, "David S. Miller" <davem@...emloft.net>, 
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>, 
	Neal Cardwell <ncardwell@...gle.com>, Willem de Bruijn <willemb@...gle.com>, 
	Mina Almasry <almasrymina@...gle.com>, Kuniyuki Iwashima <kuni1840@...il.com>, bpf@...r.kernel.org, 
	netdev@...r.kernel.org
Subject: Re: [PATCH v5 bpf-next/net 4/5] net-memcg: Allow decoupling memcg
 from global protocol memory accounting.

On Fri, Sep 5, 2025 at 2:25 PM Shakeel Butt <shakeel.butt@...ux.dev> wrote:
>
> On Thu, Sep 04, 2025 at 01:21:47PM -0700, Kuniyuki Iwashima wrote:
> > On Wed, Sep 3, 2025 at 11:35 PM Johannes Weiner <hannes@...xchg.org> wrote:
> > >
> > > On Wed, Sep 03, 2025 at 07:02:03PM +0000, Kuniyuki Iwashima wrote:
> > > > If all workloads were guaranteed to be controlled under memcg, the issue
> > > > could be worked around by setting tcp_mem[0~2] to UINT_MAX.
> > > >
> > > > In reality, this assumption does not always hold, and processes not
> > > > controlled by memcg lose the seatbelt and can consume memory up to
> > > > the global limit, becoming noisy neighbour.
> > >
> > > It's been repeatedly pointed out to you that this container
> > > configuration is not, and cannot be, supported. Processes not
> > > controlled by memcg have many avenues to become noisy neighbors in a
> > > multi-tenant system.
> > >
> > > So my NAK still applies. Please carry this forward in all future patch
> > > submissions even if your implementation changes.
> >
> > I see.
> >
> > I'm waiting for Shakeel's response as he agreed on decoupling
> > memcg and tcp_mem and suggested the bpf approach.
>
> Yes I agreed on decoupling memcg and tcp_mem but not for a weird
> configuration, so please stop using this motivatioan already. You can
> motivate the decoupling simply on performance. Why pay the cost
> of two orthogonal accounting mechanisms concurrently? Also you are not
> disabling memcg accounting, so we should be good from memcg side. Make
> this very clear in your commit message.
>
> I don't care how you plan to use this feature to enable your weird
> use-case but make sure this feature is beneficial to general Linux
> users.

Thank you Shakeel, I will rephrase the commit messages and
clarify the points above.