On 10/06, Jan Kratochvil wrote:
>
> On Mon, 05 Oct 2009 04:32:08 +0200, Oleg Nesterov wrote:
> [...]
> > Firstly, I think we should un-revert 
> > edaba2c5334492f82d39ec35637c6dea5176a977.
> > This unconditional wakeup is hopelessly wrong imho, and it is removed
> > from utrace-ptrace code. But this breaks another test-case,
> > attach-wait-on-stopped. I still think this test-case is wrong.
> > We had a lengthy discussion about this.
> >
> > Now, this patch
> >
> >     --- TTT_32/kernel/signal.c~PT_STOP      2009-10-04 04:08:36.000000000 
> > +0200
> >     +++ TTT_32/kernel/signal.c      2009-10-05 03:17:39.000000000 +0200
> >     @@ -1708,7 +1708,7 @@ static int do_signal_stop(int signr)
> >              */
> >             if (sig->group_stop_count) {
> >                     if (!--sig->group_stop_count)
> >     -                       sig->flags = SIGNAL_STOP_STOPPED;
> >     +                       sig->flags = SIGNAL_STOP_STOPPED | 
> > SIGNAL_STOP_DEQUEUED;
> >                     current->exit_code = sig->group_exit_code;
> >                     __set_current_state(TASK_STOPPED);
> >             }
> >
> > fixes the tests above. Of course this change is not enough, I did
> > it just to verify I really understand what happens.
> >
> > Except, stopped-attach-transparency prints
> >
> >     Excessive waiting SIGSTOP after the second attach/detach
> >
> > afaics the test-case is not right here. attach_detach() leaves the
> > traced threads in STOPPED state, why pid_notifying_sigstop() should
> > fail?
>
> Tried the patch above:
>       http://koji.fedoraproject.org/scratch/jkratoch/task_1730038/
>
> but it does not break stopped-attach-transparency for me.

You mean, it doesn't fix stopped-attach-transparency?

Strange... I tested it, with this patch stopped-attach-transparency
succeeds on my machine.

But! please note "this change is not enough" above, the right fix
is not simple. However I thought it should work in this case...

> Should I also apply back edaba2c5334492f82d39ec35637c6dea5176a977?

This revert should be unreverted anyway, imho. This wakeup is wrong
in many ways, but note that the changelog says in particular:

        this wake_up_process() can break another
        assumption: PTRACE_DETACH with SIGSTOP should leave the tracee in
        TASK_STOPPED case.  Because the untraced child can dequeue SIGSTOP and
        call do_signal_stop() before ptrace_detach() calls wake_up_process().

However, this race is unlikely, I don't think it can explain why
stopped-attach-transparency fails with the patch above.

Oleg.

Reply via email to