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 for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date:   Sat, 24 Apr 2021 14:54:26 +0300
From:   Vasily Averin <vvs@...tuozzo.com>
To:     Michal Hocko <mhocko@...e.com>, cgroups@...r.kernel.org
Cc:     linux-kernel@...r.kernel.org, Roman Gushchin <guro@...com>,
        Christian Brauner <christian.brauner@...ntu.com>,
        Michal Koutný <mkoutny@...e.com>,
        Serge Hallyn <serge@...lyn.com>
Subject: [PATCH v2 0/1] memcg: enable accounting for pids in nested pid
 namespaces

Pid was one the first kernel objects enabled for memcg accounting, see
5d097056c9a0 ("kmemcg: account certain kmem allocations to memcg")

init_pid_ns.pid_cachep marked by SLAB_ACCOUNT and we can expect that any new pids 
in the system are memcg-accounted.

Though recently I've noticed that it is wrong. nested pid namespaces creates 
own slab caches for pid objects, nested pids have increased size because contain 
id both for all parent and for own pid namespaces. The problem is that these slab
caches are _NOT_ marked by SLAB_ACCOUNT,as a result any pids allocated in 
nested pid namespaces are not memcg-accounted.

Pid struct in nested pid namespace consumes up to 500 bytes memory,
100000 such objects gives us up to ~50Mb unaccounted memory.
This allow container to exceed assigned memcg limits.

For me this issue lookslike bug and I would like to ask to push this fix 
both to upstream and to stable

Vasily Averin (1):
  memcg: enable accounting for pids in nested pid namespaces

 kernel/pid_namespace.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

-- 
1.8.3.1

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ