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: <sathtxzxvi5zz5gh37twfng7srn7nsdlrdlposompqkq646pp5@2r74fqgbalzq>
Date: Fri, 5 Sep 2025 14:25:37 -0700
From: Shakeel Butt <shakeel.butt@...ux.dev>
To: Kuniyuki Iwashima <kuniyu@...gle.com>
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 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ