Messages in this thread | | | Date | Fri, 28 Nov 2008 10:38:26 +0800 | From | Li Zefan <> | Subject | Re: [RFC][PATCH 1/2] CGROUP ID and Hierarchy Code |
| |
KAMEZAWA Hiroyuki wrote: > On Fri, 28 Nov 2008 10:35:33 +0900 > KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> wrote: > >> On Fri, 28 Nov 2008 09:28:33 +0800 >> Li Zefan <lizf@cn.fujitsu.com> wrote: > >>> I think the safe way is: >>> >>> rcu_read_lock(); >>> cgrp = cgroup_get_next() >>> if (!inc_not_zero(cgrp) { >>> rcu_read_unlock(); >>> return NULL; >>> } >>> rcu_read_unlock(); >>> return cgrp; >>> >>> But it's also safe to use cgrp = list_entry(&parent->children.next) for the above >>> scenario, seems you don't have to invent this cgroup_get_next(). >>> >> But list-walk can't provide us view of hierarchy. Up-Down list walk is better ? >> please see memcg's code. it met some troubles. >> I'll make kfree(cgrp) to be called by RCU. >> > > Ah please, I have a question. > Following is right ? > - until mount, cgroup's subsystem root is tied to dummy? root cgroup.
Yes.
> - cgroup cannot be unmounted while there are any children.
No, you can unmount. You can have it a try. :)
> - cgroup_root is freed/allocated at umount/mount, then I have to handle
No, kill_sb() is called when deactivate_super() decreases sb->s_active to 0, and whenever we create a cgroup, sb->s_active is increased, so if there are sub-dirs the cgroup_root won't be freed at umount.
> this event in cgroup-id. > (maybe current code has leak? in umount.) >
So I think there is no leak. ;)
> Thanks, > -Kame > > >
| |