Messages in this thread | | | Date | Tue, 15 Feb 2011 16:58:48 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang after PTRACE_ATTACH |
| |
Hello Tejun,
On 02/15, Tejun Heo wrote: > > Hello, Oleg, Denys. > > On Mon, Feb 14, 2011 at 09:01:30PM +0100, Oleg Nesterov wrote: > > > Or we can avoid entering TASK_TRACED on ptrace(PTRACE_GETSIGINFO) et al. > > > Can we remain in TASK_STOPPED? > > > > Oh, unlikely, I think. > > 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?
I do not think this is really wrong (except this means another user visible change and I never know if it is fine).
But I think it doesn't really help. Yes, this is probably enough for strace (I don't know for sure) , but a more "sophisticated" debugger may want to do something else with the stopped tracee.
And. Denys suggested this assuming PTRACE_CONT-doesnt-resume-until-SIGCONT, and in this case this is not really needed. The debugger can safely do PTRACE_GETSIGINFO even if this changes the state to TASK_TRACED. Once it does PTRACE_CONT the tracee becomes "visible" to SIGCONT. Or, if SIGCONT comes in between, the tracee runs.
Oleg.
| |