Messages in this thread Patch in this message | | | From | Denys Vlasenko <> | Subject | Re: [PATCH 04/11] ptrace: implement PTRACE_INTERRUPT | Date | Sun, 8 May 2011 23:58:20 +0200 |
| |
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
| |