Thread (29 messages) 29 messages, 3 authors, 2012-03-23

Re: Q: cgroup: Questions about possible issues in cgroup locking

From: Mandeep Singh Baines <hidden>
Date: 2012-01-04 19:36:33
Also in: lkml

Oleg Nesterov (oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org) wrote:
On 12/21, Frederic Weisbecker wrote:
quoted
On Wed, Dec 21, 2011 at 11:24:13AM -0800, Mandeep Singh Baines wrote:
quoted
If you call exec from a thread other than g, g is now unlinked. So
"t != g" will always be true. If you then pthread_create, you now
have two threads so "t != __prev" will also always be true. So
you now have an infinite loop.
Oh you're right.

But then we can't use t != t->group_leader because that assumes while_each_thread()
started on the leader.
Yes, this can't work.

Besides, we need more burriers to rely on the ->group_leader check.

See http://marc.info/?t=127688987300002
I went through the thread. Were there any other concerns other than
requiring that you start with the group_leader and the barrier?

You could modify zap_other_threads to start with the group leader by
skipping p:

if (p == t)
   continue;
in particular, http://marc.info/?l=linux-kernel&m=127714242731448
I think this should work, but then we should do something with the
users like zap_threads().
With that patch, won't you potentially miss the exec thread if an exec
occurs while you're iterating over the list? Is that OK?

Regards,
Mandeep
Oleg.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help