Re: [PATCH 04/11] ptrace: implement PTRACE_INTERRUPT

[Tejun Heo <tj@kernel.org>]

Hello,

On Wed, May 11, 2011 at 12:20:11PM -0400, Bryan Donlan wrote:
> If a process issues PTRACE_INTERRUPT, it just wants the target process
> to stop. Presumably it doesn't really care _why_, as long as it
> doesn't introduce spurious effects visible to the target. As such, if
> the process stops on its own due to some other trap, that ought to be
> good enough, right? Is there really a need for a trap that will be
> reliably echoed back to the trapping process?

It can go either way.  I just chose one.  One use case which made me
favor not clearing INTERRUPT on other traps was that INTERRUPT, along
with group stop trap, is special in that it allows notification
re-traps.  It serves as per-tracee job control trap site which
debugger can use as it pleases.

As such, there are times where debugger wants to put tracee into that
specific trap.  If INTERRUPT gets cleared on every trap, it would have
to set INTERRUPT on each trap until it reaches INTERRUPT trap which
seemed kinda silly and given that INTERRUPT may happen for spurious
notification reasons, there didn't seem much point in avoiding the
trap because there was another trap.

That said, as it makes INTERRUPT behavior different from SEIZE and I
think occassional multiple traps on SEIZE could be uglier.  I think
I'll change it such that it clears on any trap.  If debugger wants to
put tracee specifically into INTERRUPT trap, it will have to raise it
after each unsuccessful trap.  It would be annoying but I suppose it's
lesser of the two evils.

Thanks.

-- 
tejun