lkml.org 
[lkml]   [2011]   [May]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 10/10] ptrace: implement group stop notification for ptracer
On 05/19, Tejun Heo wrote:
>
> Hey,
>
> On Thu, May 19, 2011 at 06:32:46PM +0200, Oleg Nesterov wrote:
> > > +static void ptrace_trap_notify(struct task_struct *t)
> > > +{
> > > + siginfo_t *si = t->last_siginfo;
> > > +
> > > + WARN_ON_ONCE(!(t->ptrace & PT_SEIZED));
> > > + assert_spin_locked(&t->sighand->siglock);
> > > +
> > > + /*
> > > + * @t is being ptraced and new SEIZE behavior is in effect.
> > > + * Schedule sticky trap which will clear on the next GETSIGINFO.
> > > + */
> > > + t->jobctl |= JOBCTL_TRAP_NOTIFY;
> >
> > This is also set by do_signal_stop(). Cleared by PTRACE_GETSIGINFO.
> >
> > How can this work? Doesn't this mean PTRACE_GETSIGINFO becomes mandatory
> > before PTRACE_CONT? IOW, unless the tracee does PTRACE_GETSIGINFO to clear
> > this bit, PTRACE_CONT just leads to another trap, no?
>
> Yes, group stop state change raises a sticky trap condition which is
> cleared by GETSIGINFO.

Hmm. At least now I understand the meaining what "sticky" means in
this discussion ;) I was confused.

> > > + if (task_is_traced(t) && si && si->si_code == PTRACE_STOP_SI_CODE) {
> >
> > OK, this PTRACE_STOP_SI_CODE check is clear. But the same check in
> > ptrace_check_attach() looks confusing, why can't we set BLOCK_NOTIFY
> > unconditionally?
>
> It's an optimization. If we set the flag, we'll have to acquire
> siglock

OK, I see.

> > > + t->jobctl |= JOBCTL_TRAPPING;
> > > + if (!(t->jobctl & JOBCTL_BLOCK_NOTIFY))
> > > + signal_wake_up(t, true);
> >
> > Could you please remind me why we can't avoid the awful ptrace_wait_trapping()
> > in do_wait() paths? Assuming that ptrace_check_attach() does this. I got lost
> > a bit.
>
> Please consider the following scenario.
>
> 1. Tracee is in group stop and stops at TRAP_STOP notifying the
> tracer.
>
> 2. Tracer does WNOWAIT wait(2) and determines that the tracee is
> trapped in TRAP_STOP.
>
> 3. Something generates SIGCONT which finishes the group stop and
> triggers the notification re-trapping.
>
> 4. While tracee is re-trapping, tracer issues WNOHANG

OK. I still hope we can avoid this somehow. May be play with exit_code
so that do_wait() can succeed even if the JOBCTL_TRAPPING tracee is
running. Perhaps.

If only we could notify the tracer from ptrace_trap_notify... IIUC,
this is the only problem? I mean, apart from this there is no need
to wake up the tracee.

Oleg.



\
 
 \ /
  Last update: 2011-05-19 19:17    [from the cache]
©2003-2011 Jasper Spaans