netdev - Re: [RFC] net: make net.core.{r,w}mem

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: <1501579980.1163602.1059346360.66293F3A@webmail.messagingengine.com>
Date:   Tue, 01 Aug 2017 11:33:00 +0200
From:   Hannes Frederic Sowa <hannes@...essinduktion.org>
To:     Eric Dumazet <eric.dumazet@...il.com>
Cc:     Matteo Croce <mcroce@...hat.com>, netdev@...r.kernel.org
Subject: Re: [RFC] net: make net.core.{r,w}mem_{default,max} namespaced

On Tue, Aug 1, 2017, at 09:18, Eric Dumazet wrote:
> On Tue, 2017-08-01 at 02:17 -0400, Hannes Frederic Sowa wrote:
> 
> > We do account rmem as well as wmem allocated memory to the apropriate
> > mem_cgs. In theory this should be okay.
> 
> Last time I checked, rmem was not memcg ready yet.
> 
> Can you describe the details ?

As long as our packets pass __sock_queue_rcv_skb (what we do with udp,
raw, packet) we call down to sk_rmem_schedule, which in
__sk_mem_schedule -> sk_mem_raise_allocated will charge the mem_cg or
suppress the allocation.

For tcp, as I remember from the last discussion, we simply drop packets
and don't handle that very sensible, albeit we should not get out of the
mem_cg limits.

tcp_try_rmem_schedule in front of the ofo as well as the data queue
should make sure of that. Did I overlook anything?

OTOH, I am not too fond of the change. I just think that it shouldn't
deplete memory but rather stall connections.

Thanks,
Hannes