Messages in this thread | | | Date | Sun, 8 Sep 2013 18:00:07 +0200 | From | Oleg Nesterov <> | Subject | Re: CGROUP 관련 문의 |
| |
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 linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |