lkml.org 
[lkml]   [2011]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
DateThu, 2 Jun 2011 14:03:40 +0900
FromTejun Heo <>
SubjectRe: [PATCH 01/17] ptrace: remove silly wait_trap variable from ptrace_attach()
Hello,

On Wed, Jun 01, 2011 at 08:47:43PM +0200, Oleg Nesterov wrote:
> On 05/30, Tejun Heo wrote:
> > - if (wait_trap)
> > - wait_event(current->signal->wait_chldexit,
> > - !(task->group_stop & GROUP_STOP_TRAPPING));
> > + wait_event(current->signal->wait_chldexit,
> > + !(task->group_stop & GROUP_STOP_TRAPPING));
> > return retval;
>
> Well, it doesn't change anything, but only if ptrace_attach() succeeds.
> The caller should not wait if STOP_TRAPPING was already set by another
> tracer and we are going to fail. Afaics, nothing really bad can happen
> but still this doesn't look very clean.
>
> And. Please note that this patch is buggy until 8/17 "use bit_waitqueue
> for TRAPPING", wait_event(current->signal->wait_chldexit) can hang forever
> in this case since we are not ->parent.

Ah, darn it. It was part of later patch which got dropped and I just
salavaged this part and put it at the front forgetting about the
chldexit conversion.

> I agree, wait_trap should go away. We can hit STOP_TRAPPING after attach
> if we change detach to set this bit. But perhaps it would be more clean
> to not call wait_event/wait_bit unconditionally anyway, we can check
> retval == 0.

Yeap, that sounds about right. Will post updated patch.

Thanks.

--
tejun


\
 
 \ /
  Last update: 2011-06-02 07:05    [from the cache]
©2003-2010