Re: [RFC] Proposal for ptrace improvements

[Tejun Heo <tj@kernel.org>]

Hey, Oleg.

On Thu, Mar 03, 2011 at 09:22:46PM +0100, Oleg Nesterov wrote:
> On 03/03, Oleg Nesterov wrote:
> >
> > I'll ask the questions later.
> 
> Right now I do not see any holes (but I'll try more ;)

Heh, I'm sure you'll find some. :-)

> One question, to ensure I really understand you. To simplify,
> consider this particular example.
> 
> Tracee:
> 
> 	int main(void)
> 	{
> 		kill(SIGSTOP, getpid());
> 
> 		printf("I am running\n");
> 
> 		for (;;)
> 			;
> 	}
> 
> To simplify again, suppose that the debugger attaches when it is
> already stopped, then it does PTRACE_CONT(0).
> 
> In this case the tracee remains SIGNAL_STOP_STOPPED but prints
> "I am running" and enters the endless loop.
> 
> (the new debugger can do PTRACE_SEIZE after that and "return"
>  it to the stopped state without affecting jctl state).
> 
> Now, if SIGCONT comes (from anywhere) it clears SIGNAL_STOP_STOPPED,
> the tracee traps and reports this event to debugger.
> 
> Correct?

The notification of the end of job control stop (ie. emission of
SIGCONT) is probably the most hazy part and probably would change a
bit while implemented, but here are the baselines I have on mind.

* The notification of the job control stop itself is the only time
  that wait(2) reports the job control signal and the siginfo which
  was sent together.

* When job control stop ends, exit_code is changed to indicate ptrace
  trap and siginfo indicates the trap site and that job control stop
  is no long in effect.  This of course should wake up the tracer if
  it's wait(2)ing.

* The above requires another ptrace trap site which can probably
  shared with PTRACE_SEIZE.  The question is whether to make group
  stop state available for other trap sites too or just enable it in
  the new trap site.  ATM, I'm leaning toward the latter.

> And, once again. In the mt case, I assume that SIGCONT makes
> every traced thread to report this event individually, right?
>
> (I am talking about the case when the group-stop was finished,
>  iow "every" probably means the threads which participated and
>  reported CLD_STOPPED to the debugger).

Yeap, it's per-task ptrace trap which is broadcasted to every ptraced
task which participated in the group stop.

> In both cases, later then this SIGCONT will be reported again
> as any "normal" signal when some thread dequeues it.

Yeap, that's something which happens in the delivery path for SIGCONT.
It should behave the same (other than fixing notification to real
parent, that is).

> Is my understanding correct?

Yeap, seems pretty accurate.

Thank you.

-- 
tejun