linux-kernel - Re: [PATCH] new cgroup controller "fork"

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

Message-ID: <20111104135943.GB14377@tango.0pointer.de>
Date:	Fri, 4 Nov 2011 14:59:43 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	Glauber Costa <glommer@...allels.com>,
	"Brian K. White" <brian@...ex.com>, cgroups@...r.kernel.org,
	containers@...ts.linux-foundation.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] new cgroup controller "fork"

On Fri, 04.11.11 11:03, Li Zefan (lizf@...fujitsu.com) wrote:

> >> Sure many other processes would legitimately fork/die/fork/die a lot
> >> while never exceeding a few total concurrent tasks, and for them you
> >> would not want to set any such fork limit. So what?
> >>
> > As I said previously, he knows his use cases better than anyone else.
> > If a use case can be found in which the summation of cpu+task controllers is not enough, and if this is implemented as an option to the task controller, and does not make it:
> > 1) confusing,
> > 2) more expensive,
> > 
> > then I don't see why not we shouldn't take it.
> 
> Quoted from Lennart's reply in another mail thread:
> 
> "Given that shutting down some services might involve forking off a few
> things (think: a shell script handling shutdown which forks off a couple
> of shell utilities) we'd want something that is between "from now on no
> forking at all" and "unlimited forking". This could be done in many
> different ways: we'd be happy if we could do time-based rate limiting,
> but we'd also be fine with defining a certain budget of additional forks
> a cgroup can do (i.e. "from now on you can do 50 more forks, then you'll
> get EPERM)."
> 
> (http://lkml.org/lkml/2011/10/19/468)
> 
> The last sentence suggests he might like this fork controller.

Yes, indeed. Limiting forks like this would be pretty much exactly what
we need in systemd to make the shutdown of services robust towards
code which tries to fork faster than we could kill it. I am all in
favour of this code, especially due to its simplicity.

However, I'd like to see this implemented as part of the core cgroup
interfaces, instead of an independent controller. Otherwise we might
have multiple userspace frameworks fighting over it: LXC might want to
take posession of it, systemd too, and Max' own CGI tool might as
well. I believe limiting forks like this is an important part of the
basic cgroup management that userspace needs, independently of what a
specific software actually wants to do with it (i.e. which cgroup
controller it wants to use, if any), and it hence should be available in
all hierarchies, including the named ones that are useful to ensure that
a specific controller is not monopolized by one userspace consumer.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.
--
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/