Messages in this thread | | | Date | Thu, 11 Feb 2010 11:08:24 -0800 | Subject | Re: Race in ptrace. | From | Salman Qazi <> |
| |
I understand what it does. But, why is it the right thing to do? From the user's perspective, why should the task become untraced if we use ptrace to deliver the signal? Doesn't this make it impossible to intercept and control which signals are sent to a traced task?
On Thu, Feb 11, 2010 at 10:55 AM, Oleg Nesterov <oleg@redhat.com> wrote: > On 02/11, Salman Qazi wrote: >> >> >> > // the tracee is STOPPED as requested, not TRACED, >> >> > // SIGCONT wakes it up >> >> > kill(pid, SIGCONT); >> >> I am still missing something. There's probably a gap in my >> understanding, so let's try to clarify it. The last "kill" call, >> sends a SIGCONT. But, shouldn't this SIGCONT be intercepted by the >> tracer before the tracee sees it? > > No. The tracee resumes (again: because it was STOPPED, not TRACED), > dequeues SIGCONT, reports the signal and stops in TASK_TRACED, > see ptrace_signal(). Meanwhile, until it calls ptrace_stop(), it is > TASK_RUNNING and ptrace() fails. > > Oleg. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |