Messages in this thread |  | | | Date | Mon, 30 Mar 2009 03:22:04 +0200 | | From | Oleg Nesterov <> | | Subject | Re: [patch 3/14] x86, ptrace, bts: stop bts tracing early in do_exit |
| |
On 03/28, Markus Metzger wrote: > > ds_release_bts(struct bts_tracer *tracer) > { > struct task_struct *task = > tracer->ds.context->task; > > do { > set_task_state(task, TASK_UNINTERRUPTIBLE);
Oh, this is not right,
> while (!wait_task_inactive(task, TASK_UNINTERRUPTIBLE));
and can't help to wait_task_inactive(). Again, unless this task does a blocking call wait_task_inactive() can't force this task to be deactivated. Even we set TASK_UNINTERRUPTIBLE.
> ds_suspend_bts(tracer); > ds_free_bts(tracer); > > wake_up_process(task);
makes it TASK_RUNNING. This can't restores the proper ->state if it was not running (say, TASK_STOPPED).
> } > > I guess it would not work in general, since task could already sleep > on some event and be woken up after the do loop.
This too,
> I was thinking it might work for the exit race, since we don't sleep > during exit,
We do. In the context of bts problems, we don't care if the task sleeps after _free_tracee(). But this task can have tracees too, it can in turn sleep in wait_task_inactive().
> Isn't this a general problem for ptrace? > > Ptrace uses a similar pattern in ptrace_check_attach(). > It stops the traced task, but that task might wake up immediately after > that check. It might be scheduled in any time during a ptrace operation.
Yes. ptrace() can assume the tracee is TASK_TRACED, or it is dying/dead.
If you need to make sure it is still traced, you can re-check ->state under ->siglock. Until you drop this lock, the tracee (if still traced) can't escape from ptrace_stop/do_signal_stop, even if scheduled.
Oleg.
|  |