Messages in this thread | | | Date | Thu, 23 Dec 2010 17:06:48 +0100 | From | Oleg Nesterov <> | Subject | Re: [PATCH 09/16] ptrace: make do_signal_stop() use ptrace_stop() if the task is being ptraced |
| |
On 12/23, Tejun Heo wrote: > > > int main(void) > > { > > int child, status; > > > > child = fork(); > > if (!child) { > > ptrace(PTRACE_TRACEME); > > > > kill(getpid(), SIGSTOP); > > > > return 0; > > } > > > > wait(&status) > > // the tracee reports the signal > > assert(WIFSTOPPED() && WSTOPSIG() == SIGSTOP); > > // it should stop after that > > ptrace(PTRACE_CONT, child, SIGSTOP); > > > > wait(&status); > > // now it is stopped > > assert(WIFSTOPPED() && WSTOPSIG() == SIGSTOP); > > > > kill(child, SIGCONT); > > > > wait(&status); > > assert(WIFSTOPPED() && WSTOPSIG() == SIGCONT); > > > > This won't work with this patch. the last do_wait() will hang forever. > > Probably this is fine, I do not know. Please take a look and ack/nack > > explicitly. > > Yes, before the change, the task would respond to SIGCONT before the > first ptrace request succeeds after attach.
Not exactly. But perhaps you meant that even without this change, any ptrace() request after ptrace(PTRACE_CONT, SIGSTOP) will change child->state = TASK_TRACED, and kill(SIGCONT) won't work after that.
> To me, this doesn't seem > to be anything intentional tho. It seems a lot of ptrace and group > stop interactions is in the grey area with only the current (quirky, > I'm afraid) behavior drawing almost arbitrary lines across different > behaviors.
Agreed.
However. Strangely, I didn't think about this before. With this change, it is not possible to trace/debug the application so that it can properly react to SIGCONT. Yes, currently we have a lot more problems here, including do_wait, so probably this doesn't matter.
Still I'd like to know what Jan and Roland think. I am paranoid, yes ;)
> Anyways, pondering and verifying all the possibly visible changes > definitely is necessary, but that said, we fortunately have rather > limited number of ptrace users and their usages don't seem to be too > wild (at least on my cursory investigation), so I think it to be > doable without breaking anything noticeably. But yeap we definitely > need to be careful.
Yes, at least I think it makes sense to document this change in the changelog. This can simplify the life if we have a bug report blaiming this patch.
> And, for longer term, I think it would be a good idea to separate > group stop and ptrace trap mechanisms, so that ptrace trap works > properly on per-task level and properly transparent from group stop > handling. The intertwining between the two across different domains > of threads inhfferently involves a lot of grey areas where there is no > good intuitive behavior.
Agreed.
> Not really sure why > skipping it didn't cause any problem until now tho.
Yes, that was my question.
Oleg.
| |