Re: [PATCH 06/11] ptrace: make group stop state visible via PTRACE_GETSIGINFO

[Oleg Nesterov <oleg@redhat.com>]

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.