mirror of
https://github.com/team-infusion-developers/android_kernel_samsung_msm8976.git
synced 2024-11-07 04:09:21 +00:00
[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>
This commit is contained in:
parent
3f17da6994
commit
dadac81b1b
1 changed files with 2 additions and 2 deletions
|
@ -1173,8 +1173,6 @@ static task_t *copy_process(unsigned long clone_flags,
|
|||
if (unlikely(p->ptrace & PT_PTRACED))
|
||||
__ptrace_link(p, current->parent);
|
||||
|
||||
attach_pid(p, PIDTYPE_PID, p->pid);
|
||||
attach_pid(p, PIDTYPE_TGID, p->tgid);
|
||||
if (thread_group_leader(p)) {
|
||||
p->signal->tty = current->signal->tty;
|
||||
p->signal->pgrp = process_group(current);
|
||||
|
@ -1184,6 +1182,8 @@ static task_t *copy_process(unsigned long clone_flags,
|
|||
if (p->pid)
|
||||
__get_cpu_var(process_counts)++;
|
||||
}
|
||||
attach_pid(p, PIDTYPE_TGID, p->tgid);
|
||||
attach_pid(p, PIDTYPE_PID, p->pid);
|
||||
|
||||
nr_threads++;
|
||||
total_forks++;
|
||||
|
|
Loading…
Reference in a new issue