Re: [patch] proposed fix for ptrace() SMP race

[David Mosberger]

>>>>> On Fri, 7 Sep 2001 03:28:01 +0200, Andrea Arcangeli <[e-mail]> said:

  Andrea> For making sure the task isn't wakenup while it's under
  Andrea> ptrace we should just do that in
  Andrea> kernel/signal.c::ignored_signal() as far I can tell.

This doesn't make sense: ignored_signal() is too late as
handle_stop_signal() will already have woken up the task in response
to a SIGCONT.  Also, if you're suggesting to ignore SIGCONT while a
PT_PTRACED is set, that certainly wouldn't be right.  We only want to
*delay* the wakeup while the ptrace() system call is running (which is
much shorter than the period of time PT_PTRACED is set).  So, as far
as I can tell, you'd have to add more locking to the signal path,
which doesn't look attractive to me. Also, if pursuing approach, we'd
have to prove that we cover all possible paths that could wake up the
task.  E.g., PTRACE_SYSCALL and PTRACE_CONT are other ways the task
could be woken up.  These particular cases should be fine, because
they'll already be serialized by the BKL acquired during ptrace(), but
I'm not so sure there aren't any other cases.

So, I still think cpus_allowed is a safer and better approach at least
for 2.4.  Yes, we'd have to add locking for writing cpus_allowed, but
I'd say that makes sense anyhow given that it is being manipulated by
other tasks.

Hmmh, looking at ptrace() more closely, the entire locking situation
seems to be a bit confused.  For example, what's stopping wait4() from
releasing the task structure just after ptrace() released the
tasklist_lock and before it checked child->state?

	--david