• Oleg Nesterov's avatar
    [PATCH] fix kill_proc_info() vs fork() theoretical race · dadac81b
    Oleg Nesterov authored
    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: default avatarOleg Nesterov <oleg@tv-sign.ru>
    Cc: Roland McGrath <roland@redhat.com>
    Cc: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
    dadac81b
fork.c 38.5 KB