On cgroup, cpuset and rcu and a patch.
From: Peter Zijlstra
Date: Tue Dec 15 2009 - 12:18:14 EST
Hi Paul,
I'm wanting to use cpuset_cpus_allowed_locked() from within a scheduler
path (to break affinity in some rare cases), this however precludes that
I hold any mutex.
>From what I can see, its perfectly safe to use guarantee_online_cpus()
without holding any mutex, or even task_lock(), as long as I hold the
RCU read-lock, since cgroups are RCU-freed and task_cs() includes the
appropriate rcu_dereference(), and cgroup_attach_task() includes the
matching rcu_assign_pointer() call.
Or is there still any merit to the cpuset comments and am I missing some
detail -- which then ought to get fixed?
Also, while looking over the cgroup code, I found the below...
---
Subject: cgroup: fix RCU assumptions
The code relies on RCU read-lock to iterate the task list, but fails to
actually take it.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@xxxxxxxxx>
---
kernel/cgroup.c | 2 ++
1 file changed, 2 insertions(+)
Index: linux-2.6/kernel/cgroup.c
===================================================================
--- linux-2.6.orig/kernel/cgroup.c
+++ linux-2.6/kernel/cgroup.c
@@ -2127,6 +2127,7 @@ static void cgroup_enable_task_cg_lists(
struct task_struct *p, *g;
write_lock(&css_set_lock);
use_task_css_set_links = 1;
+ rcu_read_lock();
do_each_thread(g, p) {
task_lock(p);
/*
@@ -2138,6 +2139,7 @@ static void cgroup_enable_task_cg_lists(
list_add(&p->cg_list, &p->cgroups->tasks);
task_unlock(p);
} while_each_thread(g, p);
+ rcu_read_unlock();
write_unlock(&css_set_lock);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/