Re: PTRACE_SEIZE should not stop [Re: [PATCH 02/11] ptrace:implement PTRACE_SEIZE]

[Tejun Heo]

Hello, Jan.

On Mon, May 16, 2011 at 03:21:23PM +0200, Jan Kratochvil wrote:
> Currently that waitpid will report SIGUSR1 first and then the INTERRUPT trap.

Yes, it would.

> I suggest - if possible - that tracer will get that INTERRUPT trap first.
> 
> But you made the optimization that the INTERRUPT gets suppressed in such case.
> Which improves performance for the cost of more complicated debuggers.

INTERRUPT is suppressed if group stop is pending not signal.  That was
more about duplicity between INTERRUPT trap and group stop, which made
the whole thing uglier.  I merged the two together so there's no such
distinction anymore.

> I guess after PTRACE_SEIZE if the first signal/event is not INTERRUPT there
> will not be any INTERRUPT later, as you said.

I replied in another message too but now SEIZE and INTERRUPT behave
identically.  Any trap clears the condition.

I don't think INTERRUPT can be prioritized like that above existing
trap conditions.  Traps are taken sometimes deep in the kernel
(e.g. fork/exec) and often after modifying states irrevocably
(e.g. signal is already dequeued on signal trap).  I don't think how
it would be possible to rewind the state changes and replay it later.

FWIW, if INTERRUPT exists while signal is pending, INTERRUPT will be
taken first but that doesn't mean all that much as we can't roll back
from traps which already have happened and tracee might be in any trap
by the time PTRACE_INTERRUPT is issued.

Thank you.

-- 
tejun
--
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/