Re: [PATCH] cgroup: fix to allow mounting a hierarchy by name

[Li Zefan]

Tejun Heo wrote:
> Hello,
> 
> On Fri, Dec 30, 2011 at 01:58:52PM +0800, Li Zefan wrote:
>> Normal filesystems can have multi mount points, and an fs instance
>> is identified by device name, but cgroupfs ignores device name like
>> other pseudo filesystems. Instead a set of subsystems is used, so
>> to mount the same cgroupfs instance in different mount points, we
>> can do this:
>>
>> 	# mount -t cgroup -o cpuset xxx /cgroup1
>> 	# mount -t cgroup -o cpuset xxx /cgroup2
>>
>> Now we have the "none" option, so a cgroupfs can have no subsystems
>> bound to it, and we allow multi instances of such cgroupfs, so we
>> have to assign names to each instance:
>>
>> 	# mount -t cgroup -o none,name=hier1 xxx /cgroup1
>> 	# mount -t cgroup -o none,name=hier2 xxx /cgroup2
>>
>> Then we want to also mount "hier1" in another mount point, we can't
>> do this:
>>
>> 	# mount -t cgroup -o none xxx /mnt
>>
>> because we have two different instances with "none" subsystem. So
>> we specify its name:
>>
>> 	# mount -t cgroup -o none,name=hier1 xxx /mnt
>>
>> Hope I have made things clear to you?
> 
> mount --bind?  It's not exactly the same thing but I don't think the
> differences would matter for cgroup.

There's a corner case where "mount --bind" can't be used:

	# mount -t cgroup -o none,name=hier1 xxx /mnt
	# mkdir /mnt/tmp
	# umount /mnt

Since there's a sub-cgroup in it, umount won't destroy the hierarchy,
but "hide" it, so the name=xxx is necessary to re-mount it.

> Also, what's the use case for
> mounting the same cgroup directory multiple times?  Why is that
> necessary?  Is it useful for some namespace-savvy setup?
> 

I don't have a use case in real life. It was made so at the very
beginning of cgroup, and we should't break it without strong reasons.
We can mount other pseudo filesystems like procfs, sysfs and debugfs
multiple times, right?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/