Messages in this thread | | | Date | Tue, 15 Feb 2011 21:27:47 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE_ATTACH |
| |
On 02/15, Roland McGrath wrote: > > > Actually I was thinking along this line. We can allow > > PTRACE_GETSIGINFO to proceed without forcing the tracee into TRACED > > state, the rationale being the operation is required to tell between > > group stop and ptrace trap. Am I missing something? > > The reason for the transition to TASK_TRACED is to prevent a race with > SIGCONT waking the task. There is always a race with SIGKILL waking it, > but the circumstances where that can really matter are far fewer. > You need to make sure that the work PTRACE_GETSIGINFO does to access > last_siginfo cannot race with that pointer disappearing or the stack > space it points to becoming invalid. I think the use of siglock ensures > that, but Oleg should verify it.
Yes, I think this is safe.
I do not really like this idea because it looks a bit strange to treat PTRACE_GETSIGINFO specially, and this doesn't solve all problems. And, once again, I still hope we can change ptrace_resume() so that it doesn't wakeup the stopped (I mean, SIGNAL_STOP_STOPPED) tracee, in this case this hack is not needed.
And. We are going to add the new requests which doesn't need the stopped tracee anyway. So we can just add PTRACE_HAS_SIGINFO which returns child->last_siginfo != NULL. This looks simpler, and this is compatible. Of course this check is racy, but this doesn't matter. PTRACE_GETSIGINFO is equally racy if it doesn't change the state to TASK_TRACED.
But I won't argue if you/Denys/Tejun prefer to change PTRACE_GETSIGINFO.
Oleg.
| |