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]
Date:	Tue, 16 Nov 2010 18:03:12 +0100
From:	Lennart Poettering <mzxreary@...inter.de>
To:	Dhaval Giani <dhaval.giani@...il.com>
Cc:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Mike Galbraith <efault@....de>,
	Vivek Goyal <vgoyal@...hat.com>,
	Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Markus Trippelsdorf <markus@...ppelsdorf.de>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Balbir Singh <balbir@...ux.vnet.ibm.com>
Subject: Re: [RFC/RFT PATCH v3] sched: automated per tty task groups

On Tue, 16.11.10 15:47, Dhaval Giani (dhaval.giani@...il.com) wrote:

> 
> On Tue, Nov 16, 2010 at 3:11 PM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> > On Tue, 2010-11-16 at 07:02 -0700, Mike Galbraith wrote:
> >> While you can identify firefox etc,
> >> it's not being done, and requires identifying every application.  Heck,
> >> cgroups is built in, but userspace doesn't even mount.  Nothing but
> >> nothing uses cgroups.
> >
> > The yet another init rewrite called systemd is supposedly cgroup happy..
> > No idea if its going to be useful though, I doubt its going to have an
> > effect on me launching a konsole or the like, or screen creating a bunch
> > of ttys.
> 
> systemd uses cgroups only for process tracking. No resource
> management. Though afaik, Lennart has some plans of doing resource
> management using systemd. I wonder how autogroups will interact with
> systemd in that case.

systemd already creates a named cgroup for each user who logs in and each
session inside it. That's implemented via pam_systemd, which is enabled
in all distros doing systemd. We create those groups right now only in
the named "systemd" hierarchy, but iiuc then simply doing the same in
the "cpu" hierarchy would have the exact same behaviour as this patch,
but actually is based on a sane definition of what a session is.

Binding something like this to TTYs is just backwards. No graphical
session has a TTY attached anymore. And there might be multiple TTYs
used in the same session. 

I really wonder why logic like this should live in kernel space at all,
since a) the kernel has no real notion of a session, except audit and b)
this is policy and as soon as people have this kind of group then they
probably want other kind of autogrouping as well for the other
controllers, which hence means userspace is a better, and configurable
place for this.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ