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

[David Mosberger]

>>>>> On Fri, 7 Sep 2001 02:19:00 +0200, Andrea Arcangeli <[e-mail]> said:

  Andrea> Last time I checked for such race it was looking ok (on
  Andrea> x86). Do you have a testcase to demonstrate it?

For ia64, yes.  I didn't look at x86.  Other platforms may or may not
be affected, that is true, but the races are so subtle, I'd rather
make sure this problem cannot occur on any platform.

  Andrea> but it cannot be running in "userspace" any longer once it
  Andrea> is set to TASK_STOPPED which should be the _only_ thing we
  Andrea> care in ptrace. If it's still running it's in its way to
  Andrea> schedule() a few lines after the setting of tsk->state to
  Andrea> TASK_STOPPED and that's ok for ptrace.

Yes, the code running in schedule() is sufficient.  On ia64, what
happened is that switch_to() may end up saving the floating-point
registers f32-f127.  After doing so, it will set a bit in the thread
flags and since this is done non-atomically (for good reason), it
creates a race with the code in ptrace() which also updates the thread
flags.

  Andrea> abusing cpus_allowed to forbid scheduling is racy so quite
  Andrea> unacceptable, we want to preserve the cpus_allowed field for
  Andrea> the administrator (he could as well set it during the
  Andrea> ptrace).

As long as the CPU manipulates cpus_allowed in an atomic fashion (xchg
or cmpxchg) this will be fine.  I'd argue it has to do this anyhow
(unless a task is changing its own cpus_allowed field).

If you don't like the cpus_allowed approach, please propose another
solution that ensures that the task does not get woken up while ptrace
is running.  I don't really care very much what the solution is, but I
do want to make sure we can guarantee that the task does not start
running while ptrace() is doing it's job.  Having to prove that race
conditions in ptrace() are harmless is far too painful (and bound to
be violated as code changes in the future...).

	--david