Re: [RFC] Proposal for ptrace improvements

[Jan Kratochvil]

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.

When you check gdb-6.8.tar it asserts the first received signal is SIGSTOP or
in a different case it ignores the first signal (whatever it is).  This is
because if the programmer sees during the development the first signal that
comes is SIGSTOP (s)he automatically writes the code with that assumption.

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).

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.


Thanks,
Jan
--
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/