linux-kernel - Re: [RFD] Merge task counter into memcg

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] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Apr 2012 18:59:27 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Glauber Costa <glommer@...allels.com>
Cc:	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Tejun Heo <tj@...nel.org>, Daniel Walsh <dwalsh@...hat.com>,
	"Daniel P. Berrange" <berrange@...hat.com>,
	Li Zefan <lizf@...fujitsu.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Cgroups <cgroups@...r.kernel.org>,
	Containers <containers@...ts.linux-foundation.org>
Subject: Re: [RFD] Merge task counter into memcg

On Thu, Apr 12, 2012 at 01:34:50PM -0300, Glauber Costa wrote:
> On 04/12/2012 11:55 AM, Frederic Weisbecker wrote:
> >I don't know how the kernel stack is allocated for tasks. Do you mean
> >that we allocate a chunck of it for each new task and we could rely
> >on that?
> >
> More than this: amount of kernel stack is really, really something
> indirect if what you want to track is # of processes. Now, Hannes
> made a fair point in his other e-mail about what is a resource and
> what is not.

I start to consider this option, are there other people interested
in accounting/limiting kernel stack as well?

> 
> >>>  After all, we would only restrict the number of tasks for the
> >>>  resources they require
> >It depends if the kernel stack can have other kind of "consumer".
> >
> It also depends on what you really want to achieve.
> If you want to prevent fork bombs, limiting kernel stack will do just fine.

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. 

> 
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/