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    [W:2.158 / U:0.268 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site