The forked child can have TIF_SIGPENDING if it was copied from parent's
ti->flags. But this is harmless and actually almost never happens, because
copy_process() can't succeed if signal_pending() == T.
Signed-off-by: Oleg Nesterov <[email protected]>
--- PTRACE/kernel/fork.c~FORK_SIGPENDING 2009-04-13 17:05:52.000000000 +0200
+++ PTRACE/kernel/fork.c 2009-04-27 21:38:57.000000000 +0200
@@ -1027,7 +1027,6 @@ static struct task_struct *copy_process(
p->vfork_done = NULL;
spin_lock_init(&p->alloc_lock);
- clear_tsk_thread_flag(p, TIF_SIGPENDING);
init_sigpending(&p->pending);
p->utime = cputime_zero;
Acked-by: Roland McGrath <[email protected]>
> The forked child can have TIF_SIGPENDING if it was copied from parent's
> ti->flags. But this is harmless and actually almost never happens, because
> copy_process() can't succeed if signal_pending() == T.
When it does happen, it's actually improper to clear it. In a CLONE_THREAD
case, the pending signals might include shared_pending signals that the
child too should take. (Arguably there is no way to notice, since the
parent thread will be racing to dequeue the same signals.)
Thanks,
Roland
On 04/27, Roland McGrath wrote:
>
> Acked-by: Roland McGrath <[email protected]>
>
> > The forked child can have TIF_SIGPENDING if it was copied from parent's
> > ti->flags. But this is harmless and actually almost never happens, because
> > copy_process() can't succeed if signal_pending() == T.
>
> When it does happen, it's actually improper to clear it. In a CLONE_THREAD
> case, the pending signals might include shared_pending signals that the
> child too should take. (Arguably there is no way to notice, since the
> parent thread will be racing to dequeue the same signals.)
Yes, sure. Now I see the changelog is not very clear.
I meant, it is possible that the parent has the false TIF_SIGPENDING which
is cleared later by recalc_sigpending(). In this case it is correct to do
clear_tsk_thread_flag(p, TIF_SIGPENDING), but this almost never happens.
Oleg.