Hi Tejun, On 10/21, Tejun Heo wrote: > > On Sun, Oct 21, 2012 at 09:11:41PM +0200, Oleg Nesterov wrote: > > > And it seems that fork() can race with cgroup iterator. post_fork > > will notice use_task_css_set_links, but until then the child belongs > > to the parent's css and it is not "visible" to iterator (and right > > after cgroup_fork() it is not visible to do_each_thread() if > > use_task_css_set_links is not set). > > > > For example. Suppose that the child migrates to another cgroup after > > copy_process() makes it visible to the user-space. Then update_if_frozen > > sets CGROUP_FROZEN (again, cgroup_iter_next do not see this child). > > > > Now, post_fork calls freezer_fork() and hits BUG_ON(CGROUP_FROZEN). > > > > But again, I do not blame this patch. > > I'm planning to update it to, > > * Clear ->cgroup to %NULL during copy_process(). I completely agree. new_child->cgroups copied from parent looks simply strange until post_fork. If nothing else, the new task is still under construction by the time cgroup_fork() is called. > > I am starting to think again about a big-rw-lock around copy_process. > > Recently I tried to add one around dup_mmap for uprobes, but perhaps > > cgroups can use it too... > > If some other subsystems need it, maybe just make threadgroup locking > coarser? What do you mean? > I *think* I can make cgroup work correctly without a agiant > rwlock Yes, probably cgroup doesn't really need it. Although we could probably kill signal->group_rwsem, but this is minor and "write-lock" will be much slower. Oleg. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
