Re: [patch 3/14] x86, ptrace, bts: stop bts tracing early in do_exit

[Oleg Nesterov <oleg@redhat.com>]

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.