Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang afterPTRACE_ATTACH

[Oleg Nesterov]

On 02/14, Denys Vlasenko wrote:
>
> On Wednesday 09 February 2011 22:25, Oleg Nesterov wrote:
> >
> > But yes: this is what the current code does, I am not sure we can
> > change this, and both PTRACE_CONT-doesnt-resume-until-SIGCONT and
> > PTRACE_CONT-acts-as-SIGCONT are not "perfect" too.
>
> Can you enumerate reasons why each of them are not perfect?
> I want to understand your thinking better here.

Standard answer: this can break things ;)

Also, PTRACE_CONT-acts-as-SIGCONT looks a bit ugly, it can wakeup
other tracees (or we can turn them into TASK_TRACED, I dunno).

> > Yes, and this race is already here, ptracer should take care.
>
> From the API POV, there is no race,

Sorry for confusion... I just meant that if the tracee is TASK_STOPPED
then ptrace(PTRACE_WHATEVER) can always fail if it races with SIGCONT
from the third party.

> > > In either case, the fundamentals of ptrace operation don't really
> > > change.  All ptrace operations are still per-task and ptracer almost
> > > always has control over execution of the tracee.  Sure, it allows
> > > ptraced task to escape group stop but it seems defined clear enough
> > > and IMHO actually is a helpful debugging feature.
> >
> > Heh, I think we found the place where we can't convince each other.
> > What if we toss a coin?
>
> I'm with Oleg on this. If debugger wants to terminate group-stop,
> it should just send SIGCONT, not depend on the obscure feature (it is not
> documented, right?) that PTRACE_CONT somehow affects group-stop state.

Yes, this is PTRACE_CONT-doesnt-resume-until-SIGCONT suggested by Roland.

But Tejun rightly points this can confuse gdb (and nobody knows what
else ;) Can we do this change and require the applications to learn
the new rules? I do not know.

> > I hate this from the time when I noticed that the application doesn't
> > respond to ^Z under strace. And I used strace exactly because I wanted
> > do debug some (I can't recall exactly) problems with jctl. That is all.
>
> Recently I had exactly this experience too. It's frustrating.

Agreed.

> You just succeeded :)

Thanks ;)

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/