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

[David Mosberger <davidm@hpl.hp.com>]

>>>>> On Fri, 7 Sep 2001 15:28:58 +0200, Andrea Arcangeli <andrea@suse.de> said:

  Andrea> correct, I suggest to ignore SIGCONT as well while
  Andrea> PT_PTRACED is set.

Do you really think it's acceptable?  With your patch, you couldn't
SIGKILL or SIGCONT a task that happens to be ptraced.  I certainly
would expect to be able to do this for a task that is being strace'd,
for example.

Also, other signals will still wake up the task.  Yes, it won't get
very far as do_signal() will notify the parent instead, but still, the
task will run and that could be enough to create some race condition.

What about the other wakeup paths that I had mentioned?  E.g., what if
the ptraced task is ptracing another task?  Couldn't notify_parent()
end up waking up the task as well?

  Andrea> Also when you restore the cpus_allowed you won't effectively
  Andrea> wakup the task, it will just keep floating in the runqueue
  Andrea> but we won't try to reschedule the other idle cpus it so
  Andrea> it's broken.

Ah, that's a good point, thanks.  Nothing that can't be fixed, though.

  >> 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?

  Andrea> the get_task_struct()

Yes, I missed that.

	--david