Re: [PATCH] task: Make task list manipulations RCU safe.

[ebiederm@xmission.com (Eric W. Biederman)]

Oleg Nesterov <oleg@tv-sign.ru> writes:

> Some questions.
>
> first_tgid:
> 	...
> 	for (; pos && pid_alive(pos); pos = next_task(pos))
>
> I think this patch makes this 'pid_alive(pos)' unneeded?

Close.  The problem is that we could have slept with the
count elevated on start before we do rcu_read_lock().

> next_tgid:
> 	rcu_read_lock();
> 	pos = start;
> 	if (pid_alive(start))
> 		pos = next_task(start);
> 	if (pid_alive(pos) && (pos != &init_task)) {
> 		get_task_struct(pos);
> 		goto done;
> 	}
>
> The first 'pid_alive()' check is quite understandable.
> What about the second one? I beleive, now it is unneeded
> as well. The same for first_tid/next_tid.

Agreed.  Since we are guaranteed that ->next will still
be valid we should be able to get this down to a single
pid_alive check.  Although I'm not certain I would want
to return a task that had just died from either of these functions.
But I guess the race is there regardless.

> Also, first_tid() does 'task_lock(leader)' while reading
> ->signal->count. Why? ->signal is protected by ->siglock,
> but we don't need any locks because ->signal is rcu safe.
> Same for proc_task_getattr(), s/task_lock/rcu_read_lock/.

Probably my general paranoia.  I know I didn't quite grok
rcu at the time I wrote that code, and I could have easily
gotten confused about what task_lock protects.  Looks like
I need to generate a patch to cleanup that one.

Eric

-
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/