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

[Denys Vlasenko <vda.linux@googlemail.com>]

On Sunday 08 May 2011 17:48, Tejun Heo wrote:
> Currently, there's no way to trap a running ptracee short of sending a
> signal which has various side effects.  This patch implements
> PTRACE_INTERRUPT which traps ptracee without any signal or job control
> related side effect.

What are the rules for the userspace? You said about PTRACE_SEIZE:

> After PTRACE_SEIZE, tracee will trap.  Which trap will happen isn't
> fixed.  If other trap conditions exist (signal delivery or group
> stop), they might be taken; otherwise, a trap with exit_code SIGTRAP |
> (PTRACE_EVENT_INTERRUPT << 8) is taken.  The followings are
> guaranteed.
> 
> * A trap will happen in finite amount of userland time.
> 
> * The trap can be PTRACE_EVENT_INTERRUPT which doesn't have any side
>   effect.  If a different trap is taken, no INTERRUPT trap is pending.
> 
> IOW, no matter what, one trap will happen, which might be INTERRUPT.

Are rules for PTRACE_INTERRUPT the same? That is, what happens
if a different trap is taken?

Can you add API notes in the header, above corresponding defines? -

--- a/include/linux/ptrace.h
+++ b/include/linux/ptrace.h
@@ -48,6 +48,7 @@
 #define PTRACE_SETREGSET       0x4205
 
<============================================ ADD COMMENT HERE
 #define PTRACE_SEIZE           0x4206
<============================================ ADD COMMENT HERE
+#define PTRACE_INTERRUPT       0x4207


They will be much more visible and up-to-date there than in Documentation,
git logs etc...

And finally, thanks for working on the long-needed evolutionary fixes to ptrace!

-- 
vda