On Fri, Feb 26, 2010 at 2:01 PM, KAMEZAWA Hiroyuki <kamezawa.hiroyu@xxxxxxxxxxxxxx> wrote: > Hi, > > On Fri, 26 Feb 2010 13:50:04 +0900 > Minchan Kim <minchan.kim@xxxxxxxxx> wrote: > >> > Hm ? I don't read the whole thread but can_attach() is called under >> > cgroup_mutex(). So, it doesn't need to use RCU. >> >> Vivek mentioned memcg is protected by RCU if I understand his intention right. >> So I commented that without enough knowledge of memcg. >> After your comment, I dive into the code. >> >> Just out of curiosity. >> >> Really, memcg is protected by RCU? > yes. All cgroup subsystem is protected by RCU. > >> I think most of RCU around memcg is for protecting task_struct and >> cgroup_subsys_state. >> The memcg is protected by cgroup_mutex as you mentioned. >> Am I missing something? > > There are several levels of protections. > > cgroup subsystem's ->destroy() call back is finally called by > > As this. > > 768 synchronize_rcu(); > 769 > 770 mutex_lock(&cgroup_mutex); > 771 /* > 772 * Release the subsystem state objects. > 773 */ > 774 for_each_subsys(cgrp->root, ss) > 775 ss->destroy(ss, cgrp); > 776 > 777 cgrp->root->number_of_cgroups--; > 778 mutex_unlock(&cgroup_mutex); > > Before here, > - there are no tasks under this cgroup (cgroup's refcnt is 0) > && cgroup is marked as REMOVED. > > Then, this access > rcu_read_lock(); > mem = mem_cgroup_from_task(task); > if (css_tryget(mem->css)) <===============checks cgroup refcnt If it it, do we always need css_tryget after mem_cgroup_from_task without cgroup_mutex to make sure css is vaild? But I found several cases that don't call css_tryget 1. mm_match_cgroup It's used by page_referenced_xxx. so we I think we don't grab cgroup_mutex at that time. 2. mem_cgroup_oom_called I think in here we don't grab cgroup_mutex, too. I guess some design would cover that problems. Could you tell me if you don't mind? Sorry for bothering you. Thanks, Kame. -- Kind regards, Minchan Kim _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers