linux-kernel - Re: [PATCH 00/11 v5] cgroups: Task counter subsystem

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]

Message-Id: <20110913152302.6c33ea6d.akpm@google.com>
Date:	Tue, 13 Sep 2011 15:23:02 -0700
From:	Andrew Morton <akpm@...gle.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Paul Menage <paul@...lmenage.org>,
	Li Zefan <lizf@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Aditya Kali <adityakali@...gle.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Kay Sievers <kay.sievers@...y.org>,
	Tim Hockin <thockin@...kin.org>, Tejun Heo <tj@...nel.org>,
	Containers <containers@...ts.osdl.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH 00/11 v5] cgroups: Task counter subsystem

On Tue, 13 Sep 2011 01:11:20 +0200
Frederic Weisbecker <fweisbec@...il.com> wrote:

> No functional changes. Only documentation and comments added.
> Checkpatch.pl fixes, etc...
> 

What is the actual rationale for merging all of this?  For this amount
of complexity I do think we need to see significant end-user benefits. 
But all I'm seeing in this patchset is

       This is a step to be able to isolate a bit more a cgroup
       against the rest of the system and limit the global impact of a
       fork bomb inside a given cgroup.

which is really very thin.

Also, the changelogs don't appear to mention any testing results for
the fork-bomb-killer feature.

Is the fork-bomb-killer feature realistically useful?  As I understand
it, the problem with a fork-bomb is that it causes a huge swapstorm
while creating tasks very quickly.  The latency impact of the swapping
makes it very hard to regain control of the system so you can stop the
forking.  So to be effective, this feature would need to limit the
swapping?  Or something.  More substantiation, please.

Also, what is the relationship between this and RLIMIT_NPROC?  Given
that we have user namespaces, does that give us per-user,
per-namespace, per-container rlimits?  If it doesn't, should it?  Will
it?  If it does/will, how duplicative will that be?
--
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/