Files
linux/kernel
Oleg Nesterov dadac81b1b [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>
2006-02-15 10:21:24 -08:00
..
2006-01-08 20:13:48 -08:00
2006-01-11 18:42:13 -08:00
2006-01-18 19:20:30 -08:00
2006-02-03 08:32:06 -08:00
2005-04-16 15:20:36 -07:00
2005-04-16 15:20:36 -07:00
2005-04-16 15:20:36 -07:00
2005-10-30 17:37:32 -08:00
2006-01-11 18:42:13 -08:00
2005-10-08 15:00:57 -07:00
2005-10-30 17:37:17 -08:00
2006-01-09 15:59:19 -08:00
2006-01-08 20:13:40 -08:00
2005-07-07 18:23:46 -07:00
2005-04-16 15:20:36 -07:00
2005-09-10 10:06:21 -07:00
2006-02-07 20:57:47 -05:00
2006-02-07 20:57:42 -05:00
2006-01-11 18:42:13 -08:00
2005-04-16 15:20:36 -07:00