lkml.org 
[lkml]   [2006]   [Mar]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] task: Make task list manipulations RCU safe.
From
Date
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/

\
 
 \ /
  Last update: 2006-03-14 19:11    [W:0.036 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site