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:	Wed, 18 Apr 2012 17:42:30 +0900
From:	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
CC:	Glauber Costa <glommer@...allels.com>, Tejun Heo <tj@...nel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Hugh Dickins <hughd@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.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

(2012/04/18 16:53), Frederic Weisbecker wrote:

> 2012/4/18 KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>:
>> (2012/04/18 1:52), Glauber Costa wrote:
>>
>>>
>>>>> In short, I don't think it's better to have task-counting and fd-counting in memcg.
>>>>> It's kmem, but it's more than that, I think.
>>>>> Please provide subsys like ulimit.
>>>>
>>>> So, you think that while kmem would be enough to prevent fork-bombs,
>>>> it would still make sense to limit in more traditional ways
>>>> (ie. ulimit style object limits).  Hmmm....
>>>>
>>>
>>> I personally think this is namespaces business, not cgroups.
>>> If you have a process namespace, an interface that works to limit the
>>> number of processes should keep working given the constraints you are
>>> given.
>>>
>>> What doesn't make sense, is to create a *new* interface to limit
>>> something that doesn't really need to be limited, just because you
>>> limited a similar resource before.
>>>
>>
>>
>> Ok, limitiing forkbomb is unnecessary. ulimit+namespace should work.
>> What we need is user-id namespace, isn't it ? If we have that, ulimit
>> works enough fine, no overheads.
> 
> I have considered using NR_PROC rlimit on top of user namespaces to
> fight forkbombs inside a container.
> ie: one user namespace per container with its own rlimit.
> 
> But it doesn't work because we can have multiuser apps running in a
> single container.
> 

Ok, then, requirements is different from ulimit. ok, please forget my words.

My concern for using 'kmem' is that size of object can be changed, and set up
may be more complicated than limiting 'number' of tasks.
It's very architecture dependent....But hmm... 

If slab accounting can handle task_struct accounting, all you wants can be
done by it (maybe). And implementation can be duplicated.
(But another aspect of the problem will be speed of development..)

One idea is (I'm not sure good or bad)...having following control files.

 - memory.kmem.task_struct.limit_in_bytes
 - memory.kmem.task_struct.usage_in_bytes
 - memory.kmem.task_struct.size_in_bytes   # size of task struct.

At 1st, implement this by accounting task struct(or some) directly.
Later, if we can, replace the implementation with slab(kmem) cgroup..
and unify interfaces.....a long way to go.

2nd idea is

 - memory.object.task.limit_in_number	# limit the number of tasks.
 - memory.object.task.usage_in_number   # usage


If I'm a user, I prefer #2.

Hmm, 
   global kmem limiting           -> done by bytes.
   special kernel object limiting -> done by the number of objects.

is...complicated ?

Thanks,
-Kame

--
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/