On 05/31, Roland McGrath wrote:
>
> ACK on the 2.6.30 patch attached.
Thanks, I am adding your Acked-by to tha patch.
> > So, I am going to send the patch below. But this leads to another question:
> > should not we move these sigaddset() + set_tsk_thread_flag() into
> > ptrace_init_task() ?
>
> It might make sense to consolidate them. But note that ptrace_attach()
> uses send_sig_info(). With SEND_SIG_FORCED, this does almost nothing more
> than sigaddset() (i.e. no queue entry). But it does do prepare_signal(),
> which will clear any pending SIGCONTs. It's possible that something in
> userland manages to rely on that behavior for the asynchronous attach case
> (unrelated to startup-time races). It wouldn't hurt for the creation-time
> case to use send_sig_info() too, though it would go through a bunch more
> code to do nothing effectual but sigaddset() in the end.
Oh, I never thought about attach && SIGCONT interaction...
But, tracehook_report_clone() has the same problems?
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.
Or do you mean something else?
Oleg.
> 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.
> 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().
Thanks,
Roland
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.
> I suspect you misread my previous question.
Apparently so.
> 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().
You mean from tracehook_report_clone to ptrace_init_task. Perhaps.
tracehook_finish_clone->ptrace_init_task is inside write_lock_irq,
so it should really be kept to the minimum of what has to be inside there.
But the real reason is just that tracehook_report_clone() is called at the
place in do_fork() where the ptrace SIGSTOP code was originally before the
introduction of tracehook.h.
This is where the utrace attachment point has to be (i.e. outside all the
locking). So I don't see any benefit to changing the ptrace status quo now
for its own sake.
Thanks,
Roland
On 06/01, Roland McGrath wrote:
>
> This is where the utrace attachment point has to be (i.e. outside all the
> locking).
Yes I see. Quoting myself:
Yes, utrace-ptrace will likely change this code further anyway
and move the code from _init() to _report_clone() back, but in this case
I guess the whole tracehook_finish_clone() will go away, so this change
looks right anyway to me.
> So I don't see any benefit to changing the ptrace status quo now
> for its own sake.
OK, agreed.
Oleg.