linux-kernel - Re: [RFC PATCH 4/4] cgroups: Add an 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] [day] [month] [year] [list]

Message-ID: <20110706004309.GB10010@somewhere.redhat.com>
Date:	Wed, 6 Jul 2011 02:43:12 +0200
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Aditya Kali <adityakali@...gle.com>
Cc:	linux-kernel@...r.kernel.org, Paul Menage <menage@...gle.com>,
	Li Zefan <lizf@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [RFC PATCH 4/4] cgroups: Add an rlimit subsystem

(restore cc list, and for real this time)

On Tue, Jun 28, 2011 at 06:08:42PM +0000, Aditya Kali wrote:
> Frederic Weisbecker <fweisbec <at> gmail.com
 
> writes:
> > +struct rlim {
> > +   struct res_counter              proc_counter;
> > +   struct cgroup_subsys_state      css;
> > +};
> This can be used to enforce limits on FDs (RLIMIT_NOFILE), TCP/UDP ports,
> locked memory, queued data on sockets, etc. How making proc_counter an
> array (currently of size 1) ? Though with this patch there is just one, but it
> will great to have ready support for easily adding more.

Yeah but Paul suggested that we don't have an all-in-one limit subsystem
but rather we group things under the same topic. If we group proc counter
and file counter under the same subsystem, we won't be able to build two
distinct hierarchies: one to deal with nr_proc and one for nr_file, and
group tasks differently inside each.

We need a higher granularity than that. And having a single nr_task susbsytem
seem to make sense as nothing else appear to be suitable to be in the same
subsystem.


>
> > +static struct cftype cft_max_proc = {
> > +   .name           = "max_proc",
> > +   .read_u64       = max_proc_read_u64,
> > +   .write_u64      = max_proc_write_u64,
> > +};
> How about exporting USAGE, MAX_USAGE and FAILCNT too? These are useful
> for resource estimation.

Usage makes sense. But do we really need the rest? May be should we wait for people
to request these?

Thanks.
--
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/