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

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

Hi,

While talking with Tejun about targetting the cgroup task counter subsystem
for the next merge window, he suggested to check if this could be merged into
the memcg subsystem rather than creating a new one cgroup subsystem just
for task count limit purpose.

So I'm pinging you guys to seek your insight.

I assume not everybody in the Cc list knows what the task counter subsystem
is all about. So here is a summary: this is a cgroup subsystem (latest version
in https://lwn.net/Articles/478631/) that keeps track of the number of tasks
present in a cgroup. Hooks are set in task fork/exit and cgroup migration to
maintain this accounting visible to a special tasks.usage file. The user can
set a limit on the number of tasks by writing on the tasks.limit file.
Further forks or cgroup migration are then rejected if the limit is exceeded.

This feature is especially useful to protect against forkbombs in containers.
Or more generally to limit the resources on the number of tasks on a cgroup
as it involves some kernel memory allocation.

Now the dilemna is how to implement it?

1) As a standalone subsystem, as it stands currently (https://lwn.net/Articles/478631/)

2) As a feature in memcg, part of the memory.kmem.* files. This makes sense
because this is about kernel memory allocation limitation. We could have a
memory.kmem.tasks.count

My personal opinion is that the task counter brings some overhead: a charge
across the whole hierarchy at every fork, and the mirrored uncharge on task exit.
And this overhead happens even in the off-case (when the task counter susbsystem
is mounted but the limit is the default: ULLONG_MAX).

So if we choose the second solution, this overhead will be added unconditionally
to memcg.
But I don't expect every users of memcg will need the task counter. So perhaps
the overhead should be kept in its own separate subsystem.

OTOH memory.kmem.* interface would have be a good fit.

What do you think?
--
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/