Messages in this thread | | | Date | Fri, 28 Nov 2008 11:41:39 +0900 | From | KAMEZAWA Hiroyuki <> | Subject | Re: [RFC][PATCH 1/2] CGROUP ID and Hierarchy Code |
| |
On Fri, 28 Nov 2008 10:38:26 +0800 Li Zefan <lizf@cn.fujitsu.com> wrote:
> 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. :) > I tried and did ;)
> > - 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. > Thank you! very helpful.
So, I should take care ofe only kill_sb() case. (it frees pointer of root (and root->topcgroup.) and I have to update it.)
Regards, -Kame
> > this event in cgroup-id. > > (maybe current code has leak? in umount.) > > > > So I think there is no leak. ;) > > > Thanks, > > -Kame > > > > > > >
| |