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

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

From: Oleg Nesterov <hidden>
Date: 2012-03-23 17:59:38
Also in: lkml

On 03/21, Mandeep Singh Baines wrote:
Oleg Nesterov (oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org) wrote:
quoted
+/*
+ * rcu-safe, but should start at ->group_leader.
+ * thread_group_leader(g) protects against the race with exec which
+ * removes the leader from list.
+ * smp_rmb() pairs with implicit mb() implied by unlock + lock in
+ * de_thread()->release_task() path.
+ */
+#define while_each_thread_rcu(g, t)				\
+	while ((t = next_thread(t)) != g &&			\
+		({ smp_rmb(); thread_group_leader(g); }))
+
Couldn't you miss the exec_thread if:

t = exec_thread && !thread_group_leader(g)
Yes, we already discussed this, iirc.

I was going to write that this is fine, but then I changed my mind.
Indeed, it is not good while_each_thread_rcu() can miss the new leader.
Could we change do_prlimit()? Especially since its slow path.
But do_prlimit() is correct. It sees the unhashed task under tasklist,
task->group_leader should be correct.
I really like you're earlier solution (ignoring barrier):

#define while_each_thread(g, t) \
	while (t->group_leader == g->group_leader && (t = next_thread(t)) != g)
The problem is "ignoring barrier and races".

OK, I'll try to think again.

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