lkml.org 
[lkml]   [2009]   [Jun]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: PATCH? tracehook_report_clone: fix false positives
On 06/01, Roland McGrath wrote:
>
> > Oh, I never thought about attach && SIGCONT interaction...
> >
> > But, tracehook_report_clone() has the same problems?
>
> I don't follow.
>
> > And if we move sigaddset to ptrace_task_init(), we should not worry about
> > SIGCONT? Without CLONE_THREAD the new task is not visible to user-space yet.
> > Even if we clone a sub-thread, ptrace_init_task() runs under ->siglock.
> > If SIGCONT is already pending, copy_process() won't succeed.
>
> It could be pending and blocked.

Yes, I missed that, thanks.

> > Or do you mean something else?
>
> Sorry, I don't think I understood what your question was.
> I just pointed out that the element of PTRACE_ATTACH semantics
> that would be changed unintentionally if you just replaced its
> send_sig_info() call with ptrace_init_task() using sigaddset().

I suspect you misread my previous question.

I didn't mean PTRACE_ATTACH should use ptrace_init_task). I just meant that
perhaps it makes sense to move sigaddset() from tracehook_finish_clone()
to tracehook_finish_clone()->ptrace_init_task().

As you correctly pointed out, this sigaddset() is not the same as
send_sig_info(), but the same is true for tracehook_finish_clone() too.

Oleg.



\
 
 \ /
  Last update: 2009-06-01 23:41    [W:3.117 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site