linux-kernel - Re: [RFC PATCH] memcg: export knobs for the defaul cgroup hierarchy

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: <20140721120219.GA12921@htj.dyndns.org>
Date:	Mon, 21 Jul 2014 08:02:19 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Michal Hocko <mhocko@...e.cz>
Cc:	Vladimir Davydov <vdavydov@...allels.com>,
	Johannes Weiner <hannes@...xchg.org>, linux-mm@...ck.org,
	LKML <linux-kernel@...r.kernel.org>,
	Hugh Dickins <hughd@...gle.com>,
	Greg Thelen <gthelen@...gle.com>,
	Glauber Costa <glommer@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
Subject: Re: [RFC PATCH] memcg: export knobs for the defaul cgroup hierarchy

Hello,

On Mon, Jul 21, 2014 at 01:46:55PM +0200, Michal Hocko wrote:
> Even then, I do not see how would this fork-bomb prevention work without
> causing OOMs and killing other processes within the group. The danger
> would be still contained in the group and prevent from the system wide
> disruption. Do we really want only such a narrow usecase?

Does that really matter?  I don't buy the usefulness of the various
suggested partial failure modes.  For example, is fork-bomb actually
something isolatable by not granting more forks?  Doing so is likely
to cripple the cgroup anyway, which apparently needed forking to
operate.  Such partial failure mode would only be useful iff the
culprit is mostly isolated even in the cgroup, stops forking once it
starts to fail, the already forked excess processes can be identified
and killed somehow without requiring forking in the cgroup, and fork
failures in other parts of the cgroup hopefully hasn't broken the
service provided by the cgroup yet.

In the long term, we should have per-cgroup OOM killing and terminate
the cgroups which fail to behave.  I think the value is in the ability
to contain such failures, not in the partial failure modes that may or
may not be salvageable without any way to systematically determine
which way the situation is.  Short of being able to detect which
specific process are fork bombing and take them out, which I don't
think can or should, I believe that fork bomb protection should be
dealt as an integral part of generic memcg operation.

Thanks.

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