lkml.org 
[lkml]   [2009]   [Mar]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateMon, 30 Mar 2009 03:22:04 +0200
FromOleg Nesterov <>
SubjectRe: [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.



\
 
 \ /
  Last update: 2009-03-30 03:29    [from the cache]
©2003-2010