| 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
| ||
|
Message-ID: <53230475.5050805@gopivotal.com> Date: Fri, 14 Mar 2014 13:30:29 +0000 From: Glyn Normington <gnormington@...ivotal.com> To: Li Zefan <lizefan@...wei.com> CC: Tejun Heo <tj@...nel.org>, linux-kernel@...r.kernel.org, Steve Powell <spowell@...ivotal.com> Subject: Re: [PATCH] control groups: documentation improvements Hi Li Thanks! Inline... Tejun: Li agrees with our reasoning on the "views" issue, but we'd like your feedback too in preparation for a new patch. Regards, Glyn & Steve On 14/03/2014 01:33, Li Zefan wrote: > On 2014/3/14 0:04, Glyn Normington wrote: >> Hi Tejun >> >> Stepping back from the patch for a while, we'd like to explore the issues you raise. Please bear with us as we try to capture the ideas precisely. >> >> Continued inline... >> >> Regards, >> Glyn (& Steve Powell, copied) >> >> On 10/03/2014 14:20, Tejun Heo wrote: >>> Hey, >>> >>> On Mon, Mar 10, 2014 at 02:17:21PM +0000, Glyn Normington wrote: >>>> Then we missed how to create a hierarchy with no associated >>>> subsystems. The only way I can think of is to use mount, specify no >>>> subsystems on -o (which defaults to all the subsystems defined in >>>> the kernel), and run it in a kernel with no subsystems defined >>>> (which seems unlikely these days). >>>> >>>> Is that what you had in mind or is there some other way of creating >>>> a hierarchy with no subsystems attached? >>> Hierarchy name should be specified "-o name=" for hierarchies w/o any >>> controllers. >> According to cgroups.txt: >> >> When passing a name=<x> option for a new hierarchy, you need to >> specify subsystems manually; the legacy behaviour of mounting all >> subsystems when none are explicitly specified is not supported when >> you give a subsystem a name. >> >> So the documentation certainly does not make it clear that it is valid to specify no subsystems. >> >> We tried this (on a 3.11 kernel) and can't get it to work: >> >> # mount -t cgroup -o name=th none /home/glyn/h1 > # mount -t cgroup -o name=th,none none /home/glyn/h1 Great! We'll make sure to document this when we submit the next version of the patch. > > and then > > # mount -t cgroup -o name=th none /home/glyn/h2 > >> mount: wrong fs type, bad option, bad superblock on none, >> missing codepage or helper program, or other error >> (for several filesystems (e.g. nfs, cifs) you might >> need a /sbin/mount.<type> helper program) In some >> cases useful info is found in syslog - try dmesg | >> tail or so >> >> Please could you supply an example which works? >> >>>>>> Clarify that subsystems may be attached to multiple hierarchies, >>>>>> although this isn't very useful, and explain what happens. >>>>> And a subsystem may only be attached to a single hierarchy. >>>> Perhaps that's what should happen, but the following experiment >>>> demonstrates a subsystem being attached to two hierarchies: >>>> >>>> $ pwd >>>> /home/vagrant >>>> $ mkdir mem1 >>>> $ mkdir mem2 >>>> $ sudo su >>>> # mount -t cgroup -o memory none /home/vagrant/mem1 >>>> # mount -t cgroup -o memory none /home/vagrant/mem2 >>>> # cd mem1 >>>> # mkdir inst1 >>>> # ls inst1 >>>> cgroup.clone_children memory.failcnt ... >>>> # ls ../mem2 >>>> cgroup.clone_children inst1 memory.limit_in_bytes ... >>>> # cd inst1 >>>> # echo 1000000 > memory.limit_in_bytes >>>> # cat memory.limit_in_bytes >>>> 1003520 >>>> # cat ../../mem2/inst1/memory.limit_in_bytes >>>> 1003520 >>>> # echo $$ > tasks >>>> # cat tasks >>>> 1365 >>>> 1409 >>>> # cat ../../mem2/inst1/tasks >>>> 1365 >>>> 1411 >>> You're mounting the same hierarchy twice. Those are two views into >>> the same hierarchy. >>> >>> Thanks. >>> >> Yes, it does appear that this is what is going on, but to explain it this way turns out to be more complicated than one might expect. Here's an attempt... >> > Yeah, this can only confuse people. > > I don't think we need extra explanation, because we all know the same > filesystem can have more than one mount point, and cgroupfs is no > different. Thanks. > >> --- >> A*hierarchy* is a non-empty set of cgroups arranged in a tree and a >> non-empty set of subsystems such that the cgroups in the hierarchy >> partition all the tasks in the system (in other words, every task in the >> system is in exactly one of the cgroups in the hierarchy) and each >> subsystem attaches its own state to each cgroup in the hierarchy. >> >> There may be zero or more active hierarchies. Each hierarchy has one >> or more views associated with it. A *view* is an instance of the cgroup >> virtual filesystem. The tree of cgroups of a hierarchy is represented >> by the directory tree in the cgroup virtual filesystem of each view of >> the hierarchy. All the directory trees in the cgroup virtual filesystem >> of the views of a given hierarchy have identical content. >> >> No subsystem may participate in more than one hierarchy. >> --- >> >> We'd also need to explain the behaviour of mount and umount with respect to views. The first time a cgroup mount is performed with a given set of subsystems, a hierarchy is created and a view of the hierarchy is created and associated with a cgroup filesystem at the mount point. Subsequently, if another cgroup mount is performed with the same set of subsystems, no new hierarchy is created but a new view of the existing hierarchy is created and associated with the cgroup filesystem at the new mount point. >> >> Unmounting a cgroup mount point destroys a particular view and destroys the hierarchy associated with the view if and only if the view is the only (remaining) view of the hierarchy. >> >> So does introducing the concept of a view really help? The wording in the patch does without the concept by allowing two "hierarchies" to have identical content (so they are indistinguishable). >> >> "views" don't seem to have any practical benefit. If we can avoid explaining concepts which have no use, we probably should. ;-) >> >> >> . >> -- 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