Messages in this thread | | | Subject | Re: [PATCH] task: Make task list manipulations RCU safe. | From | (Eric W. Biederman) | Date | Tue, 14 Mar 2006 11:06:52 -0700 |
| |
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/
| |