Re: [RFC] Proposal for ptrace improvements

[Tejun Heo <tj@kernel.org>]

On Fri, Mar 04, 2011 at 07:12:50PM +0100, Jan Kratochvil wrote:
> On Fri, 04 Mar 2011 18:07:37 +0100, Oleg Nesterov wrote:
> > Suppose that the tracee reports, say, a signal after PTRACE_SEIZE/INTERRUPT.
> > And this is possible anyway if the debugger races with kill(). Why this
> > is bad?
> 
> I was asking if it is possible or if it could be avoided.

First of all, if the conditions are distinguishible reliably, I think
things should be fine.  Also, after seizing, at least two conditions
must be distinguishible immediately - whether the tracee was in group
stop or just ptrace trapped, so I don't think guaranteeing single
condition is feasible to begin with.

> When the tracer has a function to attach a task it should be a self-sufficient
> function returning the tracee in some normal task like after other events.
> So the attach operation should neither leave pending some excessive signals
> nor it should eat some normal vital signals (like PTRACE_EVENT_FORK).

That was one of the reasons why I suggested PTRACE_SEIZE to be both
attach and interrupt.  In both cases, the possible states of the task
would be exactly the same.  As debugger is likely to travel various
paths in the interrupt case regularly, it will be much easier to get
it right and once you get that right, attach becomes right at no
additional cost!

> Sure the tracer can always handle it some way, ignore this signal,
> remember if it has seen that signal etc.  But if we design a new
> ptrace interface it should be simple to use and it should not
> suggest coding racy/buggy tracers.

There's no signal to ignore.  It might not be as simple as you fancy
but will (at least strive to) be reliable and race-free.  I think
racy/buggy tracers have a lot more to do with lack of documentation
and clear rules.  Everyone is left to guess and everyone of course
ends up with different conclusions.  Let's add a detailed
documentation of rules and subtleties.

Thanks.

-- 
tejun