[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100211165059.GA16053@redhat.com>
Date: Thu, 11 Feb 2010 17:50:59 +0100
From: Oleg Nesterov <oleg@...hat.com>
To: Salman Qazi <sqazi@...gle.com>
Cc: taviso@...gle.com, Roland Dreier <rolandd@...co.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Roland McGrath <roland@...hat.com>,
linux-kernel@...r.kernel.org
Subject: Re: Race in ptrace.
On 02/11, Salman Qazi wrote:
>
> On Thu, Feb 11, 2010 at 4:56 AM, Oleg Nesterov <oleg@...hat.com> wrote:
> >
> > But this all is correct, you can't expect PTRACE_SYSCALL can succeed
> > is the tracee is running, it must be stopped or traced.
> >
> > The tracee is running because it was TASK_STOPPED and antagonist()
> > sends SIGCONT.
> >
> > The tracee was TASK_STOPPED because the tracer passes sig = SIGSTOP
> > via ptrace(PTRACE_SYSCALL, WSTOPSIG(status).
> >
> > Where do you see the bug?
>
> Shouldn't ptrace(PTRACE_SYSCALL, WSTOPSIG(status)...), cause any
> future signals to the child be intercepted by the parent?
Not sure I understand your question. Of course the tracee will report any
future signals signals, after it has a chance to dequeue a signal.
But if you mean that after, say, ptrace(PTRACE_SYSCALL, SIGTERM) the
tracee should report _this_ SIGTERM to the tracer - then no. Well,
actually "this depends", but if PTRACE_SYSCALL (or any other req)
is called after the tracee reported the signal - no. The signal was
already reported.
> > int main(void)
> > {
> > int stat, ret;
> > int pid = fork();
> >
> > if (!pid) {
> > ptrace(PTRACE_TRACEME, 0, NULL, NULL);
> > for (;;)
> > ;
> > }
> >
> > sleep(1); // wait for PTRACE_TRACEME
> > kill(pid, SIGSTOP);
> >
> > // the child reports SIGSTOP, it is TASK_TRACED
> > assert(pid == wait(&stat) && WIFSTOPPED(stat));
> >
> > // the tracee should stop, we pass sig = SIGSTOP
> > assert(ptrace(PTRACE_SYSCALL, pid, 0, WSTOPSIG(stat)) == 0);
> >
> > // the child reports the group stop, it is TASK_STOPPED
> > assert(pid == wait(&stat) && WIFSTOPPED(stat));
> >
> > // the tracee is STOPPED as requested, not TRACED,
> > // SIGCONT wakes it up
> > kill(pid, SIGCONT);
>
> According to the man page, any signals to the
> process are supposed to be intercepted by the parent and that is how
> one is supposed to be able to control which signals make it to the
> child. I am not sure if it makes any difference if the signal
> originates at the parent. But in our test case, it doesn't. So, why
> doesn't the parent get a notification first?
It does. You can insert another wait() (or just sleep(1)) between
kill(SIGCONT) and PTRACE_SYSCALL below, the tracee will stop to report
SIGCONT and the tracer will be notified. In this case the following
PTRACE_SYSCALL should succeed.
Perhaps I should have mentioned that the code above is racy. It is,
I only did it to simplify the explanations.
Oleg.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists