Hi Tejun,
Sorry for delay, vacation.
On 08/28, Tejun Heo wrote:
>
> Hey, oleg.
>
> Eunki is reporting a stall in the following loop in
> kernel/cgroup.c::cgroup_attach_task()
>
> On Wed, Aug 28, 2013 at 05:19:57AM +0000, 김은기 wrote:
> >
> > ---------------------------------------------------------------------------
> > rcu_read_lock();
> > do {
> > struct task_and_cgroup ent;
> >
> > /* @tsk either already exited or can't exit until the end */
> > if (tsk->flags & PF_EXITING)
> > continue;
> >
> > /* as per above, nr_threads may decrease, but not increase. */
> > BUG_ON(i >= group_size);
> > ent.task = tsk;
> > ent.cgrp = task_cgroup_from_root(tsk, root);
> > /* nothing to do if this task is already in the cgroup */
> > if (ent.cgrp == cgrp)
> > continue;
> > /*
> > * saying GFP_ATOMIC has no effect here because we did prealloc
> > * earlier, but it's good form to communicate our expectations.
> > */
> > retval = flex_array_put(group, i, &ent, GFP_ATOMIC);
> > BUG_ON(retval != 0);
> > i++;
> >
> > if (!threadgroup)
> > break;
> > } while_each_thread(leader, tsk);
> > ---------------------------------------------------------------------------------------------
>
> where the iteration goes like
>
> leader -> Task1 -> Task2 -> Task3 -> Task1
>
> ie. leader seems RCU unlinked. Looking at the users of
> while_each_thread(), I'm confused about its locking requirements.
In short: it is broken. This was already discussed several times but
every time I was distracted.
I already have the patches somewhere (probably not 100% finished),
will try to return to this problem soon.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
