Messages in this thread | | | Date | Wed, 29 Oct 2014 10:16:40 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH] sched: Fix race between task_group and sched_task_group |
| |
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.
| |