Oleg Nesterov <[email protected]> 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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
