lkml.org 
[lkml]   [2010]   [Dec]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 10/16] ptrace: clean transitions between TASK_STOPPED and TRACED
    On 12/21, Tejun Heo wrote:
    >
    > On Mon, Dec 20, 2010 at 04:00:37PM +0100, Oleg Nesterov wrote:
    > > > +
    > > > + wait_on_bit(&child->group_stop, bit,
    > >
    > > Hmm. we could probably use ->wait_chldexit/__wake_up_parent instead,
    > > although I am not sure this would be more clean...
    >
    > Hmmmm, I actually think that would be cleaner. I just didn't know it
    > was there. Will convert over to it.

    __wake_up_parent() needs tasklist to pin ->parent. But probably in
    this particular case we can rely on rcu, or even ->siglock (given
    that attach/detach take this lock too).

    > > This doesn't work if ptrace_attach() races with clone(CLONE_STOPPED).
    > > ptrace_check_attach() can return the wrong ESRCH after that. Perhaps
    > > it is time to kill the CLONE_STOPPED code in do_fork().
    >
    > Ah, thanks for spotting it. I missed that. We should be able to
    > convert it to call ptrace_stop(), right?

    Perhaps... But then we should wakeup the new child. Perhaps we can
    just kill that code, CLONE_STOPPED is deprecated and triggers the
    warning since bdff746a (Feb 4 2008).

    > > ptrace_check_attach()->wait_on_bit() logic fixes the previous example,
    > > but:
    > >
    > > 1. the tracer knows that the tracee is stopped
    > >
    > > 2. the tracer does ptrace(ATTACH)
    > >
    > > 3. the tracer does do_wait()
    > >
    > > In this case do_wait() can see the tracee in TASK_RUNNING state,
    > > this breaks wait_task_stopped(ptrace => true).
    > >
    > > Jan?
    >
    > I see. I can move the transition wait logic into PTRACE_ATTACH.
    > Would that be good enough?

    Yes, I thought about this too. But ptrace's semantics is really strange,
    even if we move wait_on_bit() into ptrace_attach() we still have a
    user-visible change.

    sys_ptrace() only works for the single thread who did PTRACE_ATTACH,
    but do_wait() should work for its sub-threads.

    1. the tracer knows that the tracee is stopped

    2. the tracer does ptrace(ATTACH)

    3. the tracer's sub-thread does do_wait()

    Note! Personally I think we can ignore this "problem", I do not
    think it can break anything except some specialized test-case.

    > This is also related to how to wait for attach completion for a new
    > more transparent attach. Would it be better for such a request to
    > make sure the operation to complete before returning or is it
    > preferable to keep using wait(2) for that? We'll probably be able to
    > share the transition wait logic with it. I think it would be better
    > to return after the attach is actually complete but is there any
    > reason that I'm missing which makes using wait(2) preferrable?

    Oh, I do not know. This is the main problem with ptrace. You can
    always understand what the code does, but you can never know what
    was the supposed behaviour ;)

    That is why I am asking Jan and Roland who understand the userland
    needs.

    Personally, I _think_ it makes sense to keep do_wait() working after
    ptrace_attach(), if it is called by the thread which did attach.
    But perhaps even this is not really important.

    > @@ -1799,22 +1830,28 @@ static int do_signal_stop(int signr)
    > > > */
    > > > sig->group_exit_code = signr;
    > > >
    > > > - current->group_stop = gstop;
    > > > + current->group_stop &= ~GROUP_STOP_SIGMASK;
    > > > + current->group_stop |= signr | gstop;
    > > > sig->group_stop_count = 1;
    > > > - for (t = next_thread(current); t != current; t = next_thread(t))
    > > > + for (t = next_thread(current); t != current;
    > > > + t = next_thread(t)) {
    > > > + t->group_stop &= ~GROUP_STOP_SIGMASK;
    > > > /*
    > > > * Setting state to TASK_STOPPED for a group
    > > > * stop is always done with the siglock held,
    > > > * so this check has no races.
    > > > */
    > > > if (!(t->flags & PF_EXITING) && !task_is_stopped(t)) {
    > > > - t->group_stop = gstop;
    > > > + t->group_stop |= signr | gstop;
    > > > sig->group_stop_count++;
    > > > signal_wake_up(t, 0);
    > > > - } else
    > > > + } else {
    > > > task_clear_group_stop(t);
    > >
    > > This looks racy. Suppose that "current" is ptraced, in this case
    > > it can initiate the new group-stop even if SIGNAL_STOP_STOPPED
    > > is set and we have another TASK_STOPPED thead T.
    > >
    > > Suppose that another (or same) debugger ataches to this thread T,
    > > wakes it up and sets GROUP_STOP_TRAPPING.
    > >
    > > T resumes, calls ptrace_stop() in TASK_STOPPED, and temporary drops
    > > ->siglock.
    > >
    > > Now, this task_clear_group_stop(T) confuses ptrace_check_attach(T).
    > >
    > > I think ptrace_stop() should be called in TASK_RUNNING state.
    > > This also makes sense because we may call arch_ptrace_stop().
    >
    > I'm feeling a bit too dense to process the above right now. I'll
    > respond to the above next morning after a strong cup of coffee. :-)

    OK ;)

    But look. Even if the race doesn't exist. ptrace_stop() can drop
    ->siglock and call arch_ptrace_stop() which can fault/sleep/whatever.
    I think this doesn't really matter, but otoh it would be more clean
    to do this in TASK_RUNNING state anyway. At least, in anny case
    arch_ptrace_stop() can return in TASK_RUNNING.

    > > > @@ -1842,7 +1879,18 @@ static int do_signal_stop(int signr)
    > > >
    > > > spin_lock_irq(&current->sighand->siglock);
    > > > } else
    > > > - ptrace_stop(current->exit_code, CLD_STOPPED, 0, NULL);
    > > > + ptrace_stop(current->group_stop & GROUP_STOP_SIGMASK,
    > > > + CLD_STOPPED, 0, NULL);
    > >
    > > Perhaps it would be more clean to clear ->exit_code here, in the
    > > "else" branch.
    >
    > Hmmm... and dropping current->exit_code clearing from the
    > do_signal_stop(), right? I'm a bit confused about the use of
    > current->exit_code tho.

    Oh, the right answer is: ptrace shouldn't use ->exit_code at all ;)
    And its usage is very confusing.

    > Why aren't we clearing it from ptrace_stop()?

    ptrace_report_syscall() and ptrace_signal() check ->exit_code after
    return from ptrace_stop(), otherwise we ignore the "data" argument
    of ptrace_resume/ptrace_detach.

    Oleg.



    \
     
     \ /
      Last update: 2010-12-22 12:49    [W:0.031 / U:59.812 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site