lkml.org 
[lkml]   [2010]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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.



\
 
 \ /
  Last update: 2010-12-23 17:17    [from the cache]
©2003-2011 Jasper Spaans