From: Vivek Goyal <vgoyal@redhat.com>
To: Michal Hocko <mhocko@suse.cz>
Cc: Tejun Heo <tj@kernel.org>, Tim Hockin <thockin@hockin.org>,
Mike Galbraith <bitbucket@online.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Containers <containers@lists.linux-foundation.org>,
Kay Sievers <kay.sievers@vrfy.org>,
lpoetter <lpoetter@redhat.com>,
workman-devel <workman-devel@redhat.com>,
"dhaval.giani" <dhaval.giani@gmail.com>,
Cgroups <cgroups@vger.kernel.org>,
bsingharora <bsingharora@gmail.com>
Subject: Re: [Workman-devel] cgroup: status-quo and userland efforts
Date: Fri, 28 Jun 2013 14:01:55 -0400 [thread overview]
Message-ID: <20130628180155.GD16483@redhat.com> (raw)
In-Reply-To: <20130628150513.GD5125@dhcp22.suse.cz>
On Fri, Jun 28, 2013 at 05:05:13PM +0200, Michal Hocko wrote:
> On Thu 27-06-13 22:01:38, Tejun Heo wrote:
> > Hello, Mike.
> >
> > On Fri, Jun 28, 2013 at 06:49:10AM +0200, Mike Galbraith wrote:
> > > I always thought that was a very cool feature, mkdir+echo, poof done.
> > > Now maybe that interface is suboptimal for serious usage, but it makes
> > > the things usable via dirt simple scripts, very flexible, nice.
> >
> > Oh, that in itself is not bad. I mean, if you're root, it's pretty
> > easy to play with and that part is fine. But combined with the
> > hierarchical nature of cgroup and file permissions, it encourages
> > people to "deligate" subdirectories to less previledged domains,
>
> OK, this really depends on what you expose to non-root users. I have
> seen use cases where admin prepares top-level which is root-only but
> it allows creating sub-groups which are under _full_ control of the
> subdomain. This worked nicely for memcg for example because hard limit,
> oom handling and other knobs are hierarchical so the subdomain cannot
> overwrite what admin has said.
>
> > which
> > in turn leads to normal binaries to manipulate them directly, which is
> > where the horror begins. We end up exposing control knobs which are
> > tightly coupled to kernel implementation details right into lay
> > binaries and scripts directly used by end users.
> >
> > I think this is the first time this happened, which is probably why
> > nobody really noticed the mess earlier.
> >
> > Anyways, if you're root, you can keep doing whatever you want.
>
> OK, so libcgroup's rules daemon will still work and place my tasks in
> appropriate cgroups?
Do you use that daemon in practice? For user session logins, I think
systemd has plans to put user sessions in a cgroup (kind of making
pam_cgroup redundant).
Other functionality rulesengined was providing moving tasks automatically
in a cgroup based on executable name. I think that was racy and not
many people had liked it.
IIUC, systemd can't disable access to cgroupfs from other utilities.
So most likely rulesengined should contine to work. But having both
systemd and libcgroup might not make much sense though.
Thanks
Vivek
next prev parent reply other threads:[~2013-06-28 18:02 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-06 1:21 cgroup: status-quo and userland efforts Tejun Heo
2013-04-08 13:46 ` Glauber Costa
2013-04-08 18:00 ` [Workman-devel] " Vivek Goyal
2013-04-08 18:26 ` Tejun Heo
2013-04-08 23:32 ` Lennart Poettering
2013-04-09 7:37 ` Glauber Costa
2013-04-09 19:11 ` Tejun Heo
2013-04-08 17:59 ` [Workman-devel] " Vivek Goyal
2013-04-08 18:16 ` Tejun Heo
2013-04-08 18:49 ` Tejun Heo
2013-04-08 19:11 ` Vivek Goyal
2013-04-08 19:20 ` Tejun Heo
2013-04-08 19:46 ` Vivek Goyal
2013-04-08 20:02 ` Tejun Heo
2013-04-09 9:50 ` Daniel P. Berrange
2013-04-09 19:38 ` Tejun Heo
2013-04-09 19:46 ` Tejun Heo
2013-04-09 21:04 ` Serge Hallyn
2013-04-09 21:11 ` Tejun Heo
2013-04-16 11:17 ` Li Zefan
2013-04-16 17:10 ` Tejun Heo
2013-04-17 1:29 ` Li Zefan
2013-04-22 21:26 ` Tim Hockin
2013-04-22 21:41 ` Tejun Heo
2013-04-22 22:33 ` Tim Hockin
2013-06-22 23:13 ` Tim Hockin
2013-06-25 0:01 ` Tejun Heo
2013-06-25 4:07 ` Tim Hockin
2013-06-26 21:20 ` Tejun Heo
2013-06-27 0:06 ` Tim Hockin
2013-06-26 23:14 ` David Lang
2013-06-27 1:04 ` Tejun Heo
2013-06-27 3:42 ` Tim Hockin
2013-06-27 17:38 ` Tejun Heo
2013-06-27 20:46 ` Tim Hockin
2013-06-27 21:04 ` Tejun Heo
2013-06-28 18:44 ` Tim Hockin
2013-06-29 16:40 ` Tejun Heo
2015-03-03 21:53 ` Luke Leighton
2015-03-03 21:38 ` Luke Leighton
2015-03-03 21:17 ` Luke Leighton
2015-03-04 5:08 ` David Lang
2015-03-04 11:27 ` Luke Kenneth Casson Leighton
2015-03-04 20:08 ` David Lang
2013-06-27 5:45 ` Mike Galbraith
2013-06-27 13:22 ` Serge Hallyn
2013-06-27 15:29 ` Tim Hockin
2013-06-27 16:18 ` Serge Hallyn
2015-03-03 22:00 ` Luke Leighton
2013-06-27 17:48 ` Tejun Heo
2013-06-27 18:14 ` Serge Hallyn
2013-06-27 18:45 ` Tejun Heo
2013-06-27 18:51 ` Serge Hallyn
2013-06-27 18:52 ` Tejun Heo
2013-06-27 20:52 ` Tim Hockin
2015-03-03 22:08 ` Luke Leighton
2013-06-28 9:09 ` [Workman-devel] " Daniel P. Berrange
2013-06-28 15:53 ` Serge Hallyn
2013-06-28 18:58 ` Tim Hockin
2015-03-03 22:20 ` Luke Leighton
2013-06-27 18:01 ` Tejun Heo
2013-06-28 3:46 ` Mike Galbraith
2013-06-28 4:09 ` Tejun Heo
2013-06-28 4:49 ` Mike Galbraith
2013-06-28 5:01 ` Tejun Heo
2013-06-28 6:00 ` Mike Galbraith
2013-06-28 15:05 ` Michal Hocko
2013-06-28 18:01 ` Vivek Goyal [this message]
2013-06-28 19:59 ` [Workman-devel] " Daniel P. Berrange
2013-06-28 22:40 ` Serge Hallyn
2013-06-28 22:43 ` Tejun Heo
2013-06-30 18:38 ` Michal Hocko
2013-07-15 18:49 ` Vivek Goyal
2013-07-23 14:48 ` Michal Hocko
2013-06-28 18:30 ` Tejun Heo
2013-06-28 18:53 ` Tim Hockin
2013-06-29 1:48 ` Lennart Poettering
2013-06-29 3:05 ` Tim Hockin
2013-06-30 19:39 ` Lennart Poettering
2013-07-01 6:06 ` Tim Hockin
2013-07-02 23:57 ` Thomas Gleixner
2013-07-03 0:44 ` Kay Sievers
2013-07-03 7:37 ` Borislav Petkov
2013-07-03 9:30 ` Thomas Gleixner
2013-07-09 23:12 ` Jiri Kosina
2013-07-03 17:11 ` James Bottomley
2013-06-28 19:18 ` Andy Lutomirski
2013-06-28 19:36 ` Serge Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130628180155.GD16483@redhat.com \
--to=vgoyal@redhat.com \
--cc=bitbucket@online.de \
--cc=bsingharora@gmail.com \
--cc=cgroups@vger.kernel.org \
--cc=containers@lists.linux-foundation.org \
--cc=dhaval.giani@gmail.com \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lpoetter@redhat.com \
--cc=mhocko@suse.cz \
--cc=thockin@hockin.org \
--cc=tj@kernel.org \
--cc=workman-devel@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox