From: Glauber Costa <glommer@parallels.com> To: Frederic Weisbecker <fweisbec@gmail.com> Cc: Tejun Heo <tj@kernel.org>, Johannes Weiner <hannes@cmpxchg.org>, Hugh Dickins <hughd@google.com>, Andrew Morton <akpm@linux-foundation.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>, Daniel Walsh <dwalsh@redhat.com>, "Daniel P. Berrange" <berrange@redhat.com>, Li Zefan <lizf@cn.fujitsu.com>, LKML <linux-kernel@vger.kernel.org>, Cgroups <cgroups@vger.kernel.org>, Containers <containers@lists.linux-foundation.org> Subject: Re: [RFD] Merge task counter into memcg Date: Wed, 18 Apr 2012 09:00:00 -0300 [thread overview] Message-ID: <4F8EACC0.50204@parallels.com> (raw) In-Reply-To: <CAFTL4hxXT+hXWEnKop84JQ8ieHX4e=otpHnXYxdxaPgsiZYCiw@mail.gmail.com> On 04/18/2012 05:10 AM, Frederic Weisbecker wrote: > 2012/4/18 Frederic Weisbecker<fweisbec@gmail.com>: >> On Tue, Apr 17, 2012 at 08:17:53AM -0700, Tejun Heo wrote: >>> Hello, Frederic. >>> >>> On Thu, Apr 12, 2012 at 06:59:27PM +0200, Frederic Weisbecker wrote: >>>> I want: >>>> >>>> a) to prevent the forkbomb from going far enough to DDOS the machine >>>> b) to be able to kill that forkbomb once detected, in one go without race >>>> against concurrent forks. >>>> >>>> I think a) can work just fine with kernel stack limiting. I also need >>>> to be notified about the fact we reached the limit. And b) should >>>> be feasible with the help of the cgroup freezer. >>> >>> kmem allocation fail after reaching the limit which in turn should >>> fail task creation. Isn't that the same effect as the task_counter as >>> implemented? >> >> That's it. >> >>> >>>>> Is there anything for which you need to know exactly the number of >>>>> processes? >>>> >>>> No that's really about prevent/kill forkbomb as far as I'm concerned. >>> >>> Hmm... so, accounting overhead aside, if the only purpose is >>> preventing the whole machine being brought down by a fork bomb, kmem >>> limiting is enough, right? >> >> I think so yeah. > > But this needs to be a well defined kind of kmem I think. Relying on > kernel memory > alone is too general to just protect against forkbombs. Kernel stack, > OTOH, should be > a good criteria. The problem is not it being too general. The problem is it is slab-based, and it takes a lot of allocations to fill a slab page. It is a small object, but you still have one per task. If you set the limit too high, it won't help you. If you set it too low, it will harm other object users. > But now I'm worrying, do you think this kmem.kernel_stack limitation > is going to be useful > for other kind of usecase? Yes. Ultimately, we want to track as many kinds of kernel memory to avoid having one container harming the others. Page tables and stack were already briefly discussed, so I think we would get to that eventually anyway.
WARNING: multiple messages have this Message-ID (diff)
From: Glauber Costa <glommer-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> To: Frederic Weisbecker <fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> Cc: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>, Johannes Weiner <hannes-druUgvl0LCNAfugRpC6u6w@public.gmane.org>, Hugh Dickins <hughd-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>, Andrew Morton <akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>, KAMEZAWA Hiroyuki <kamezawa.hiroyu-+CUm20s59erQFUHtdCDX3A@public.gmane.org>, Daniel Walsh <dwalsh-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, "Daniel P. Berrange" <berrange-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>, Li Zefan <lizf-BthXqXjhjHXQFUHtdCDX3A@public.gmane.org>, LKML <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Cgroups <cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>, Containers <containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org> Subject: Re: [RFD] Merge task counter into memcg Date: Wed, 18 Apr 2012 09:00:00 -0300 [thread overview] Message-ID: <4F8EACC0.50204@parallels.com> (raw) In-Reply-To: <CAFTL4hxXT+hXWEnKop84JQ8ieHX4e=otpHnXYxdxaPgsiZYCiw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> On 04/18/2012 05:10 AM, Frederic Weisbecker wrote: > 2012/4/18 Frederic Weisbecker<fweisbec-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>: >> On Tue, Apr 17, 2012 at 08:17:53AM -0700, Tejun Heo wrote: >>> Hello, Frederic. >>> >>> On Thu, Apr 12, 2012 at 06:59:27PM +0200, Frederic Weisbecker wrote: >>>> I want: >>>> >>>> a) to prevent the forkbomb from going far enough to DDOS the machine >>>> b) to be able to kill that forkbomb once detected, in one go without race >>>> against concurrent forks. >>>> >>>> I think a) can work just fine with kernel stack limiting. I also need >>>> to be notified about the fact we reached the limit. And b) should >>>> be feasible with the help of the cgroup freezer. >>> >>> kmem allocation fail after reaching the limit which in turn should >>> fail task creation. Isn't that the same effect as the task_counter as >>> implemented? >> >> That's it. >> >>> >>>>> Is there anything for which you need to know exactly the number of >>>>> processes? >>>> >>>> No that's really about prevent/kill forkbomb as far as I'm concerned. >>> >>> Hmm... so, accounting overhead aside, if the only purpose is >>> preventing the whole machine being brought down by a fork bomb, kmem >>> limiting is enough, right? >> >> I think so yeah. > > But this needs to be a well defined kind of kmem I think. Relying on > kernel memory > alone is too general to just protect against forkbombs. Kernel stack, > OTOH, should be > a good criteria. The problem is not it being too general. The problem is it is slab-based, and it takes a lot of allocations to fill a slab page. It is a small object, but you still have one per task. If you set the limit too high, it won't help you. If you set it too low, it will harm other object users. > But now I'm worrying, do you think this kmem.kernel_stack limitation > is going to be useful > for other kind of usecase? Yes. Ultimately, we want to track as many kinds of kernel memory to avoid having one container harming the others. Page tables and stack were already briefly discussed, so I think we would get to that eventually anyway.
next prev parent reply other threads:[~2012-04-18 12:01 UTC|newest] Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-04-11 18:57 [RFD] Merge task counter into memcg Frederic Weisbecker 2012-04-11 18:57 ` Frederic Weisbecker [not found] ` <20120411185715.GA4317-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-11 19:21 ` Glauber Costa 2012-04-11 19:21 ` Glauber Costa 2012-04-12 11:19 ` Frederic Weisbecker 2012-04-12 11:19 ` Frederic Weisbecker [not found] ` <4F85D9C6.5000202-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-12 11:19 ` Frederic Weisbecker 2012-04-12 0:56 ` KAMEZAWA Hiroyuki 2012-04-12 1:07 ` Johannes Weiner 2012-04-12 3:56 ` Alexander Nikiforov [not found] ` <4F86527C.2080507-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 2012-04-17 1:09 ` Frederic Weisbecker 2012-04-17 1:09 ` Frederic Weisbecker 2012-04-17 1:09 ` Frederic Weisbecker 2012-04-17 6:45 ` Alexander Nikiforov 2012-04-17 6:45 ` Alexander Nikiforov 2012-04-17 15:23 ` Tejun Heo 2012-04-17 15:23 ` Tejun Heo [not found] ` <20120417152350.GC32402-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-19 3:34 ` Alexander Nikiforov 2012-04-19 3:34 ` Alexander Nikiforov [not found] ` <4F8D1171.1090504-Sze3O3UU22JBDgjK7y7TUQ@public.gmane.org> 2012-04-17 15:23 ` Tejun Heo [not found] ` <20120417010902.GA14646-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-17 6:45 ` Alexander Nikiforov 2012-04-12 4:00 ` Alexander Nikiforov 2012-04-12 4:00 ` Alexander Nikiforov 2012-04-12 0:56 ` KAMEZAWA Hiroyuki 2012-04-12 0:56 ` KAMEZAWA Hiroyuki [not found] ` <4F862851.3040208-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2012-04-12 11:32 ` Frederic Weisbecker 2012-04-12 11:32 ` Frederic Weisbecker 2012-04-12 11:43 ` Glauber Costa 2012-04-12 11:43 ` Glauber Costa [not found] ` <4F86BFC6.2050400-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-12 12:32 ` Johannes Weiner 2012-04-12 12:32 ` Johannes Weiner 2012-04-12 12:32 ` Johannes Weiner [not found] ` <20120412123256.GI1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-12 13:12 ` Glauber Costa 2012-04-12 13:12 ` Glauber Costa 2012-04-12 15:30 ` Johannes Weiner 2012-04-12 15:30 ` Johannes Weiner [not found] ` <20120412153055.GL1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-12 16:38 ` Tejun Heo 2012-04-12 16:38 ` Tejun Heo [not found] ` <20120412163825.GB13069-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-12 17:04 ` Cgroup in a single hierarchy (Was: Re: [RFD] Merge task counter into memcg) Glauber Costa 2012-04-12 17:04 ` Glauber Costa 2012-04-17 15:13 ` Tejun Heo 2012-04-17 15:13 ` Tejun Heo [not found] ` <20120417151352.GA32402-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-17 15:27 ` Glauber Costa 2012-04-17 15:27 ` Glauber Costa [not found] ` <4F870B18.5060703-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-17 15:13 ` Tejun Heo 2012-04-12 17:13 ` [RFD] Merge task counter into memcg Glauber Costa 2012-04-12 17:13 ` Glauber Costa 2012-04-12 17:23 ` Johannes Weiner 2012-04-12 17:23 ` Johannes Weiner 2012-04-12 17:23 ` Johannes Weiner [not found] ` <20120412172309.GM1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-12 17:41 ` Tejun Heo 2012-04-12 17:41 ` Tejun Heo 2012-04-12 17:53 ` Glauber Costa 2012-04-12 17:53 ` Glauber Costa 2012-04-13 1:42 ` KAMEZAWA Hiroyuki 2012-04-13 1:42 ` KAMEZAWA Hiroyuki 2012-04-17 15:41 ` Tejun Heo 2012-04-17 15:41 ` Tejun Heo 2012-04-17 16:52 ` Glauber Costa 2012-04-17 16:52 ` Glauber Costa [not found] ` <4F8D9FC4.3080800-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-18 6:51 ` KAMEZAWA Hiroyuki 2012-04-18 6:51 ` KAMEZAWA Hiroyuki 2012-04-18 6:51 ` KAMEZAWA Hiroyuki 2012-04-18 7:53 ` Frederic Weisbecker 2012-04-18 7:53 ` Frederic Weisbecker 2012-04-18 8:42 ` KAMEZAWA Hiroyuki 2012-04-18 8:42 ` KAMEZAWA Hiroyuki [not found] ` <4F8E7E76.3020202-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2012-04-18 9:12 ` Frederic Weisbecker 2012-04-18 10:39 ` Johannes Weiner 2012-04-18 9:12 ` Frederic Weisbecker 2012-04-18 9:12 ` Frederic Weisbecker 2012-04-18 10:39 ` Johannes Weiner 2012-04-18 10:39 ` Johannes Weiner 2012-04-18 11:00 ` KAMEZAWA Hiroyuki 2012-04-18 11:00 ` KAMEZAWA Hiroyuki [not found] ` <20120418103930.GA1771-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-18 11:00 ` KAMEZAWA Hiroyuki [not found] ` <CAFTL4hw3C4s6VS07pJzdBawv0ugKJJa+Vnb-Q_9FrWEq4=ka9Q-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-18 8:42 ` KAMEZAWA Hiroyuki [not found] ` <4F8E646B.1020807-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2012-04-18 7:53 ` Frederic Weisbecker [not found] ` <20120417154117.GE32402-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-17 16:52 ` Glauber Costa [not found] ` <4F878480.60505-+CUm20s59erQFUHtdCDX3A@public.gmane.org> 2012-04-13 1:50 ` Glauber Costa 2012-04-13 1:50 ` Glauber Costa 2012-04-13 2:48 ` KAMEZAWA Hiroyuki 2012-04-13 2:48 ` KAMEZAWA Hiroyuki [not found] ` <4F87865F.5060701-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-13 2:48 ` KAMEZAWA Hiroyuki 2012-04-17 15:41 ` Tejun Heo [not found] ` <20120412174155.GC13069-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-12 17:53 ` Glauber Costa 2012-04-13 1:42 ` KAMEZAWA Hiroyuki 2012-04-12 16:54 ` Glauber Costa 2012-04-12 16:54 ` Glauber Costa 2012-04-12 16:54 ` Glauber Costa [not found] ` <4F86D4BD.1040305-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-12 15:30 ` Johannes Weiner [not found] ` <20120412113217.GB11455-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-12 11:43 ` Glauber Costa 2012-04-12 1:07 ` Johannes Weiner 2012-04-12 1:07 ` Johannes Weiner [not found] ` <20120412010745.GE1787-druUgvl0LCNAfugRpC6u6w@public.gmane.org> 2012-04-12 2:15 ` Glauber Costa 2012-04-12 2:15 ` Glauber Costa 2012-04-12 3:26 ` Li Zefan 2012-04-12 3:26 ` Li Zefan 2012-04-12 14:55 ` Frederic Weisbecker 2012-04-12 14:55 ` Frederic Weisbecker [not found] ` <20120412145507.GC11455-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-12 16:34 ` Glauber Costa 2012-04-12 16:34 ` Glauber Costa [not found] ` <4F87042A.2000902-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> 2012-04-12 16:59 ` Frederic Weisbecker 2012-04-12 16:59 ` Frederic Weisbecker 2012-04-17 15:17 ` Tejun Heo 2012-04-17 15:17 ` Tejun Heo 2012-04-18 6:54 ` Frederic Weisbecker 2012-04-18 6:54 ` Frederic Weisbecker 2012-04-18 8:10 ` Frederic Weisbecker 2012-04-18 8:10 ` Frederic Weisbecker [not found] ` <CAFTL4hxXT+hXWEnKop84JQ8ieHX4e=otpHnXYxdxaPgsiZYCiw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2012-04-18 12:00 ` Glauber Costa 2012-04-18 12:00 ` Glauber Costa [this message] 2012-04-18 12:00 ` Glauber Costa 2012-04-18 8:10 ` Frederic Weisbecker [not found] ` <20120417151753.GB32402-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> 2012-04-18 6:54 ` Frederic Weisbecker [not found] ` <20120412165922.GA12484-oHC15RC7JGTpAmv0O++HtFaTQe2KTcn/@public.gmane.org> 2012-04-17 15:17 ` Tejun Heo 2012-04-11 18:57 Frederic Weisbecker
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=4F8EACC0.50204@parallels.com \ --to=glommer@parallels.com \ --cc=akpm@linux-foundation.org \ --cc=berrange@redhat.com \ --cc=cgroups@vger.kernel.org \ --cc=containers@lists.linux-foundation.org \ --cc=dwalsh@redhat.com \ --cc=fweisbec@gmail.com \ --cc=hannes@cmpxchg.org \ --cc=hughd@google.com \ --cc=kamezawa.hiroyu@jp.fujitsu.com \ --cc=linux-kernel@vger.kernel.org \ --cc=lizf@cn.fujitsu.com \ --cc=tj@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: linkBe 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.