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

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

From: Frederic Weisbecker <hidden>
Date: 2012-02-01 16:29:01
Also in: lkml

On Wed, Dec 21, 2011 at 02:08:48PM +0100, Oleg Nesterov wrote:
On 12/21, Frederic Weisbecker wrote:
quoted
- Is the check for use_task_css_set_links in cgroup_post_fork() safe? given
it is checked outside css_set_lock?

Imagine this:

CPU 0                                                        CPU 1
----                                                         -----

cgroup_enable_task_cg() {
	uset_tasks_css_set_links = 1
	for_each_thread() {
		add tasks in the list
	}
}
                                                           do_fork() {
                                                               cgroup_post_fork() {
                                                                     use_tasks_css_set_links appears
                                                                     to be equal to 0 due to write/read
                                                                      not flushed. New task won't
                                                                      appear to the list.
Yes, I was thinking about this too.

Or (I think) they can race "contrariwise". CPU_1 creates the new child,
then CPU_0 sets uset_tasks_css_set_links = 1. But afaics there is no any
guarantee that CPU_0 sees the result of list_add_tail_rcu().
Exactly! In fact even if RCU was safe with while_each_thread() it wouldn't
be enough for us because of that.

I fear we need the read_lock(tasklist_lock) here, with a pair of smp
barriers to ensure use_task_css_set_links update is visible as
expected.

I'll try to cook something.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help