linux-kernel - Re: [RFC PATCH 0/4] cgroups: Start a basic rlimit 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: <20110620191126.GB1613@somewhere>
Date:	Mon, 20 Jun 2011 21:11:33 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Paul Menage <menage@...gle.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 0/4] cgroups: Start a basic rlimit subsystem

On Mon, Jun 20, 2011 at 02:33:34PM +0800, Li Zefan wrote:
> Frederic Weisbecker wrote:
> > This starts a basic rlimit cgroup subsystem with only the
> > equivalent of RLIMIT_NPROC yet. This can be useful to limit
> > the global effects of a local fork bomb for example (local
> > in term of a cgroup).
> > 
> > The thing is further expandable to host more general resource
> > limitations in the scope of a cgroup.
> > 
> 
> As this subsystem is named "rlimit", I think we should have a bigger
> picture about how this subsystem will be.
> 
> For example, which of other RLIMIT_XXX can be make cgroup-aware in
> a meaningful way and which can't.
> 
> Another issue is, we can apply the limit of RLIMIT_NPROC as the sum
> of the tasks' limit in a cgroup, but some other RLIMIT_XXX can't
> work in this way. Take RLIMIT_NICE for example, we can apply this
> limit to each of the tasks in the cgroup.

Looking at the other rlimit options, it seems all of them can be applied
to a cgroup. They just won't all be implemented the same way.

Those that count and limit a global user resource, like NPROC, can be
implemented using the res_counter charge/uncharge that propagate the
resource consuming to the parent cgroups.

Other rlimits that are traditionally only process wide can be implemented
here as a simple limit applied to all processes in the whole cgroup.

For example RLIMIT_CORE would be a limit in any core dump on
the whole cgroup.

RLIMIT_NOFILE would be a limit on the number of files opened by the whole
cgroup.

etc...

I think they all need to be treated case by case when/if users come and propose
more rlimit options. These don't all necessary need to mirror the setrlimit
options. We could pick existing ones but change a bit their semantics to fit
more into the cgroups meaning (as a general rule any rlimit.* file must be a
cgroup wide limitation), or create new rlimit options if specific needs arise.

There can be another kind of rlimit options that can be cgroup wide but apply
per process, in which case we should tweak a bit the name of the rlimit option file.
Consider RLIMIT_STACK for example.
If we want a cgroup option that applies to the total of stack used by the whole
cgroup, the file name would be rlim.stack. If we want that limitation to happen
to the whole cgroup but per process, it would be rlim.stack_per_process.
--
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/