diff options
author | Oleg Nesterov <oleg@tv-sign.ru> | 2006-02-15 20:13:26 +0100 |
---|---|---|
committer | Linus Torvalds <torvalds@g5.osdl.org> | 2006-02-15 19:21:24 +0100 |
commit | dadac81b1b86196fcc48fb87620403c4a7174f06 (patch) | |
tree | fc19d44716915e55b237af3fb01a09f5be6d91c3 /fs/minix | |
parent | [PATCH] fix kill_proc_info() vs CLONE_THREAD race (diff) | |
download | linux-dadac81b1b86196fcc48fb87620403c4a7174f06.tar.xz linux-dadac81b1b86196fcc48fb87620403c4a7174f06.zip |
[PATCH] fix kill_proc_info() vs fork() theoretical race
copy_process:
attach_pid(p, PIDTYPE_PID, p->pid);
attach_pid(p, PIDTYPE_TGID, p->tgid);
What if kill_proc_info(p->pid) happens in between?
copy_process() holds current->sighand.siglock, so we are safe
in CLONE_THREAD case, because current->sighand == p->sighand.
Otherwise, p->sighand is unlocked, the new process is already
visible to the find_task_by_pid(), but have a copy of parent's
'struct pid' in ->pids[PIDTYPE_TGID].
This means that __group_complete_signal() may hang while doing
do ... while (next_thread() != p)
We can solve this problem if we reverse these 2 attach_pid()s:
attach_pid() does wmb()
group_send_sig_info() calls spin_lock(), which
provides a read barrier. // Yes ?
I don't think we can hit this race in practice, but still.
Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru>
Cc: Roland McGrath <roland@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Diffstat (limited to 'fs/minix')
0 files changed, 0 insertions, 0 deletions