On Wed, Oct 29, 2014 at 06:20:48AM +0300, Kirill Tkhai wrote: > > And cgroup_task_migrate() can free ->cgroups via call_rcu(). Of course, > > in practice raw_spin_lock_irq() should also act as rcu_read_lock(), but > > we should not rely on implementation details. > > Do you mean cgroup_task_migrate()->put_css_set_locked()? It's not > possible there, because old_cset->refcount is lager than 1. We increment > it in cgroup_migrate_add_src() and real freeing happens in > cgroup_migrate_finish(). These functions are around task_migrate(), they > are pair brackets. > > > task_group = tsk->cgroups[cpu_cgrp_id] can't go away because yes, if we > > race with migrate then ->attach() was not called. But it seems that in > > theory it is not safe to dereference tsk->cgroups. > > old_cset can't be freed in cgroup_task_migrate(), so we can safely > dereference it. If we've got old_cset in > cgroup_post_fork()->sched_move_task(), the right sched_task_group will > be installed by attach->sched_move_task().
Would it be fair to summarise your argument thusly: "Because sched_move_task() is only called from cgroup_subsys methods the cgroup infrastructure itself holds reference on the relevant css sets, and therefore their existence is guaranteed." ? The question then would be how do we guarantee/assert the assumption that sched_move_task() is indeed only ever called from such a method. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
