| 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: <49A34E72.1040609@cn.fujitsu.com> Date: Tue, 24 Feb 2009 09:33:38 +0800 From: Li Zefan <lizf@...fujitsu.com> To: KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com> CC: Paul Menage <menage@...gle.com>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, containers@...ts.linux-foundation.org Subject: Re: Question for remount KAMEZAWA Hiroyuki wrote: > On Mon, 23 Feb 2009 10:32:46 +0800 > Li Zefan <lizf@...fujitsu.com> wrote: > >> KAMEZAWA Hiroyuki wrote: >>> Paul Menage さんは書きました： >>>> On Fri, Feb 20, 2009 at 2:02 AM, KAMEZAWA Hiroyuki >>>> <kamezawa.hiroyu@...fujitsu.com> wrote: >>>>> 2. /proc/mounts information of release_agent should be updated.... >>>>> when it's overwritten directly. >>>> Yes, definitely. But shouldn't that happen already? >>>> cgroup_show_options() reports the current value of >>>> root->release_agent_path in /proc/mounts. Is it possible that mount is >>>> actually storing/retrieving this information in /etc/mtab, which >>>> doesn't get updated? >>>> >>> Ah, you're right. /proc/mounts is updated but /etc/mtab is not updated. >>> Hmm..from man mount(1), /etc/mtab is not synchronized with /proc/mounts. >>> Do we need to allow release_agent override at remount ? >>> >> Since we've allowed this behavior, I think we shouldn't disallow it to >> supprise users? >> > In a bit different stroy, it already surprises a user (me). > for example) > I think what may surprise people is the following mount will append opts to the original opts. > #mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge > #mount -oremount,cpuacct /cgroups,release_agent=xxxx > => remount fails. because the option "release_agent" appears twice. > > #mount -t cgroup none /cgroups -ocpu,release_agent=hogehoge > #mount -t cgroup none /cgroups -oremount,cpuacct /cgroups,release_agent=xxxx > => remount success. > > At least, updating documentation to notice this is necessary I think. > How about this: [PATCH] cgroups: more documentation for remount and release_agent This won't remove cpuacct from the mounted hierachy: # mount -t cgroup -o cpu,cpuacct xxx /mnt # mount -o remount,cpu /mnt Because for this usage mount(8) will append the new options to the original options. And this will get you right: # mount [-t cgroup] -o remount,cpu xxx /mnt Also document how to specify and change release_agent. Signed-off-by: Li Zefan <lizf@...fujitsu.com> --- diff --git a/Documentation/cgroups/cgroups.txt b/Documentation/cgroups/cgroups.txt index 93feb84..824277d 100644 --- a/Documentation/cgroups/cgroups.txt +++ b/Documentation/cgroups/cgroups.txt @@ -337,8 +337,19 @@ subsystems, type: To change the set of subsystems bound to a mounted hierarchy, just remount with different options: +# mount -o remount,cpuset,ns hier1 /dev/cgroup -# mount -o remount,cpuset,ns /dev/cgroup +Now numtasks is removed from the hierarchy and ns is added. + +Note this will add ns to the hierarchy but won't remove numtasks or +cpuset: +# mount -o remount,ns /dev/cgroup + +To Specify a hierarchy's release_agent: +# mount -t cgroup -o cpuset,release_agent="/sbin/cpuset_release_agent" \ + xxx /dev/cgroup + +Note that specifying 'release_agent' more than once will return failure. Note that changing the set of subsystems is currently only supported when the hierarchy consists of a single (root) cgroup. Supporting @@ -349,6 +360,11 @@ Then under /dev/cgroup you can find a tree that corresponds to the tree of the cgroups in the system. For instance, /dev/cgroup is the cgroup that holds the whole system. +If you want to change the value of release_agent: +# echo "/sbin/new_release_agent" > /dev/cgroup/release_agent + +It can also be changed via remount. + If you want to create a new cgroup under /dev/cgroup: # cd /dev/cgroup # mkdir my_cgroup -- 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