On 03/14/16 12:14 , Michal Hocko wrote: > On Fri 11-03-16 18:06:59, Yuriy M. Kaminskiy wrote: > [...] >> And also tried with memcg: >> t=/sys/fs/cgroup/memory/test1;mkdir $t;echo 0 >$t/tasks; >> echo 48M >$t/memory.limit_in_bytes; su testuser [...] >> and it has not helped at all (rather opposite, it ended up with killed >> init and kernel panic; well, later is pure (un)luck; but point is, memcg >> apparently *CANNOT* curb net/ns allocations). > > It seems you were using memcg v1 here. This didn't have the kernel > memory accounting enabled by default. With the v2 you get both user and
Hrr. Indeed. And used (distro) kernel compiled without MEMCG_KMEM, so this test was useless. (However, as distro kernel lacks MEMCG_KMEM, it means most users won't be able to use it as well[*], so unpriv userns are unsafe to use for all of them and should be disabled). That said, not sure if it would have helped in kernels <= 4.4 (would those allocation be called in context that allows them to be accounted by [correct] memcg?), but it looks like with upcoming change to whitelisting (explicit GPF_ACCOUNT), it won't (as almost nothing in net/* uses it). > kernel (well some subset of it) accounting enabled. Whether we account > also netns related data structures sufficiently is a question. I haven't Except for conntrack tables, it is not exactly tied to netnes, it's regular CAP_NET_ADMIN things (routing, addresses, links, iptables, etc that can be added via netlink messages). Just userns+netns gives right to tweak with them to regular user. > checked. But it would be worth trying and fix.
