Messages in this thread | | | Date | Tue, 10 May 2011 19:11:06 +0200 | From | Oleg Nesterov <> | Subject | Re: [PATCH 06/11] ptrace: make group stop state visible via PTRACE_GETSIGINFO |
| |
On 05/10, Oleg Nesterov wrote: > > > @@ -540,6 +542,17 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info) > > > > error = 0; > > *info = *child->last_siginfo; > > + > > + /* > > + * If reporting ptrace trap for a seized tracee, enable reporting > > + * of info->si_pt_flags. > > + */ > > + if ((child->ptrace & PT_SEIZED) && > > + (info->si_code & (0x7f | ~0xffff)) == (__SI_TRAP | SIGTRAP)) { > > Can't we simply check (from->si_code & __SI_MASK) == __SI_TRAP ? > > > + /* report whether group stop is in effect w/ SI_STOPPED */ > > + if (sig->group_stop_count || (sig->flags & SIGNAL_STOP_STOPPED)) > > We have more and more "group_stop_count || SIGNAL_STOP_STOPPED" checks, > perhaps we should make a helper. Or at least invent the short name to > denote the group-stopped-or-in-progress to simplify the discussions ;) > > > Still, this is strange. With this change ptrace_getsiginfo() reports > the extra "volatile" info which wasn't reported by the tracee itself. > If the tracer does PTRACE_SETSIGINFO twice in a row, it can see the ^^^^^^^^^^^^^^^^^ PTRACE_GETSIGINFO > different si_pt_flags's.
Forgot to mention... Probably we can ignore this but the tracer can set/clear __SI_TRAP via PTRACE_SETSIGINFO, after that PTRACE_GETSIGINFO changes its behaviour.
Oleg.
| |